1부 객체지향
1. 절차지향과 비교하기
객체지향 이야기가 나올 때 친구처럼 나오는 녀석이 바로 절차지향이다. 절차지향(procedure oriented) 이전에 순차지향(sequential oriented)이라는 패러다임도 있었다.
순차, 절차 이렇게 놓고 보면 둘이 차이가 있는지 헷갈린다. 하지만 영문을 잘 해석해보면 살짝 다르다는 것을 알 수 있다. 순차지향은 진짜 말그대로 순차적으로(sequential) 라는 뜻으로, 코드를 위에서 아래로 읽겠다는 의미이고, 절차지향의 procedure는 직역하면 절차가 맞지만 컴퓨터 공학에서 말하는 Procedure는 사실 함수이다. 때문에 절차지향 프로그래밍은 사실상 함수 지향 프로그래밍으로 함수 위주로 생각하고 프로그램을 만드는 패러다임이다.
이후 "객체지향의 사실과 오해"와 "오브젝트"에서 계속 이야기하던 내용을 말한다.
객체지향의 핵심은 객체가 어떤 메시지를 전달할 수 있고, 또 어떤 책임을 지게 되었으며 스스로가 그 책임을 처리하는 방법을 알고 있다는 것이다. 객체끼리 서로 협력하지만 각 객체는 서로 어떻게 일을 처리하는지 신경 쓰지 않는다. 이것이 바로 캡슐화이다. 책임은 계약이다. 수많은 객체가 협력하는 객체지향 프로그래밍에서 협력 객체들이 계약을 제대로 지키는 것을 가정하고 프로그램을 만들게 되는데 이때 사용하는 것이 테스트 코드이다. 테스트 코드를 통해 요구사항을 만족하는지 확인할 수 있다.
C언어가 객체지향 언어가 아닌 이유는 C언어의 구조체에서는 추상의 개념을 지원하지 못하기 때문이다. 자바는 인터페이스를 만들어 추상화의 원리를 이용하여 다형성을 지원하지만 C 언어의 구조체는 그렇지 못한다. 물론 누군가 구조체에서도 이렇게 저렇게 하면 책임을 할당할 수 있는데요?라고 반론할 수도 있다. 하지만 구조체의 목적은 데이터를 한 곳에 모으는 것이므로 의도와 맞지 않는다. 다시말해 구조체는 추상화를 지원하기 위해 만들어진 기능이 아니다.
2. 객체의 종류
VO(Value Object)
VO의 특징은 바로 불변성, 동등성, 자가 검증이 있다. 불변성의 특성을 지키기 위해서는 final을 사용해 불변성을 추구할 수 있다. 그리고 equals & hashCode를 재정의하여 동등성을 추구할 수 있다. 그리고 생성시 검증 로직을 추가하여 스스로 상태가 유효한지 검증할 수 있다.
책에서 불변성을 이야기 하던 중 인상 깊게 읽은 부분이 있다.
물론 객체의 불변성은 이렇게까지 복잡하고 어렵게 생각할 개념이 아니기도 합니다. 왜냐하면 객체를 진정한 의미의 불변으로 만들려고 노력하는 것은 그것 나름대로 에너지 낭비이기 떄문입니다. 노골적으로 말해서 VO의 불변성이라는 특징을 완벽하게 지키는 100점짜리 VO를 만들려고 노력할 필요도 없습니다. 중요한 것은 100점짜리 VO를 만드는 것이 아니라 불변성이 지닌 '가치'를 좇는 것입니다.
객체의 종류 47p
그동안 내가 불변성이 지닌 가치를 잊고 있지는 않았는지 다시 상기시켜주었다.
소프트웨어에서 불확실성을 없애는 것은 불가능하다. 왜냐하면 소프트웨어 개발 자체가 불확실성을 전제로 이뤄지며, 대부분의 소프트웨어는 상태 변화에 따라 다르게 동작하도록 만들어지기 때문이다. 완전히 없애는 것은 불가능하지만 최대한 줄일 수는 있다. 그래서 불확실성을 제거할 수 있는 부분과 불확실성을 안고 가야 하는 부분을 나누는 것을 시작으로 시스템에서 확실한 부분을 최대한 늘려야 한다. 그것이 바로 불변성이 추구하는 목적이다.
