코드와 모델을 밀접하게 연관시키는 것은 코드에 의미를 부여하고 모델을 적절하게 한다
객체지향 설계는 크게 3가지 단계로 나눌 수 있다
- 개념 관점 설계
- 명세 관점 설계
- 구현 관점 설계
개념 관점
개념 관점에서의 설계는 도메인 안에 존재하는 개념과 개념들 사이의 관계를 표현한다
실제의 도메인 규칙과 최대한 유사하게 반영하는 것이 핵심
명세 관점
명세 관점에서는 소프트웨어로 초점을 옮겨 객체의 인터페이스를 구성한다
객체가 협력을 위해 무엇을 할 수 있는가에 대한 명세
구현과 인터페이스를 분리하는 것은 훌륭한 객체지향 설계의
가장 기본적인 원칙이다
구현이 아니라 인터페이스에 대해 프로그래밍 하는 것
구현 관점
구현 관점에서는 객체가 어떻게 수행할 것인가에 초점을 맞추어
인터페이스를 구현하는 데 필요한 속성과 메서드를 클래스에 추가한다
개념 - 명세 - 구현의 순서로 프로그래밍을 하는 것이 아니라
각각의 다른 방향에서 바라보는 것이다
개념, 명세, 구현은 필요에 의해 변경될 수 있다
한 번에 모든 것을 완벽하게 할 수는 없다
역할, 책임, 협력을 이용해 인터페이스를 식별하고
협력에 참영하기 위해 객체가 수신해야 하는 메시지를 결정하고
메시지들이 모여 객체의 인터페이스를 구성한다
협력 안에서 메시지를 선택하고, 메시지를 수신할 객체를 선택하는 것은 명세 관점에서 인터페이스를 구성하는 것이다
커피를 주문하라 등 객체가 무엇을 해야하는지가 메시지
해당 메시지에서 커피를 주문하기 위해 필요한
메뉴, 손님, 바리스타 는 서로 협력 관계다
저자는 객체 지향에서 현실 세계를 추상화 하는 것 보다는
은유 하는 것이 더 가까운 표현이라고 주장하는 것 같다
이제는 저자의 의도를 확실히 이해했다
의심은 믿음을 주면 확신이 된다
저자의 말하기 방식이 나와 유사함을 발견했다
믿음을 주는 것은 사실을 확인 시켜주거나
사실이라고 말하기 모호한 부분들은 충분한 근거를 제시하면 된다
하지만 오래걸린다
7장 까지와서야 나는 확신을 갖는다
내가 부족하여 그런 것이겠지만
듣는 상대는 항상 해당 부분에 대해 나와 같은 수준으로
이해할 수 없다
화자는 이미 충분한 관심을 갖고 말하는 것이고
청자는 상대의 관심을 확인하자마자 자신과 다른 의견을 듣게되니
자칫 거부감을 줄 수 있다
하지만 해야할 말은 해야한다
나는 주로 해야할 말을 하는 사람일까..
정작 해야할 말은 못하고 쓸 데 없는 말을 늘어놓는 사람일까..
협력이라는 문맥에서 수신 가능한 메시지만 추려내면
객체의 인터페이스가 된다
객체가 수신한 메시지가 인터페이스를 결정한다
따라서 수신될 메시지가 구체화 혹은 변경 됨에 따라
인터페이스는 변경되어야 한다
객체들의 협력은 프로그램이 실행되는 동안 일어나는 상황을
동적으로 묘사한 모델이다
실제로 소프트웨어의 구현은 동적인 객체가 아닌
정적인 타입을 통해 이뤄진다
동적인 객체를 정적인 타입으로 추상화 하여 복잡성을 줄인다
타입은 분류를 위해 사용된다
상태와 무관하게 동일한 행동을 할 수 있는 객체들은
동일한 타입의 인스턴스로 분류할 수 있다
손님 객체는 손님 타입의 인스턴스로 볼 수 있다
포함 관계는 합성 관계라고도 한다
어느 한 쪽에 포함하지는 않지만 서로 알고있는 관계는 연관 관계
객체의 타입을 구현하는 방법은 클래스를 이용하는 것이다
협력을 통해 식별된 타입의 오퍼레이션은 외부에서 접근 가능한
공용 인터페이스의 일부다
따라서 인터페이스의 오퍼레이션 역시 외부에서 접근 가능하도록
public 으로 선언되어 있어야 한다
코드의 세 가지 관점
코드는 개념, 명세, 구현 관점에서 각기 다른 설명을 할 수 있어야 한다
공용 인터페이스는 해당 인터페이스와 협력하는 모든 객체에게 영향을 미치게 되므로 수정하기 어렵다
최대한 변화에 안정적인 인터페이스를 만들기 위해서는
구현과 관련된 세부 사항을 드러나지 않게 해야 한다
클래스의 메서드와 속성은 구현에 속하며 인터페이스의 일부가 아니다
매서드의 구현과 속성의 변경은 외부에 영향을 미쳐서는 안된다
(현실적으로는 불가능할 수도 있다)
메서드와 속성은 철저히 클래스 내부로 캡슐화 되어야 한다
훌륭한 프로그래머는 위 세가지 관점을 모두 포함하면서도
각 관점에 대응되는 요소를 명확하고 깔끔하게 드러낼 수 있어야 한다
소프트웨어는 항상 변한다
설계는 변경을 위해 존재한다
클래스가 도메인 개념을 따르면 변화에 쉽게 대응할 수 있다
