※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다.
181p~197p
협력과 메시지 파트의 용어 정리
메시지: 객체가 다른 객체와 협력하기 위해 사용하는 의사소통 메커니즘. 객체의 오퍼레이션이 실행되도록 요청하는 것을 '메시지 전송'이라고 부른다.
오퍼레이션: 객체가 다른 객체에게 제공하는 추상적인 서비스, 메시지를 수신하는 객체의 인터페이스를 강조
메서드: 메시지에 응답하기 위해 실행되는 코드 블록, 오퍼레이션의 구현
퍼블릭 인터페이스: 객체가 협력에 참여하기 위해 외부에서 수신할 수 있는 메시지의 묶음
시그니처: 시그니처는 오퍼레이션이나 메서드의 명세를 나타낸 것. 이름과 인자의 목록을 포함
인터페이스와 설계 품질
좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야 한다.
퍼블릭 인터페이스의 품질에 영향을 미치는 원칙
- 디미터 법칙
- 묻지 말고 시켜라
- 의도를 드러내는 인터페이스
- 명령-쿼리 분리
디미터 법칙
- 협력하는 객체의 내부 구조에 대한 결합으로 인해 발생하는 설계 문제를 해결하기 위해 제안된 법칙
- 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라
- '낯선 자에게 말하지 말라', '오직 인접한 이웃하고만 말하라'
- 오직 하나의 도트만 사용하라
- 디미터 법칙은 캡슐화를 협력의 관점에서 표현한 것이다.
- 부끄럼타는 코드(shy code): 불필요한 어떤 것도 다른 객채에게 보여주지 않으며, 다른 객체의 구현에 의존하지 않는 코드
- 기차충돌(train wreck): 연쇄적으로 메시지를 전송하는 형태의 코드. 클래스의 내부 구현이 외부로 노출되었을 때 나타나는 전형적인 형태
- 무비판적으로 디미터 법칙을 수용하면, 퍼블릭 인터페이스 관점에서 객체의 응집도가 낮아질 수 있다.
묻지 말고 시켜라(Tell, Don't Ask)
- 디미터 법칙은 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다는 것을 강조한다.
- 훌륭한 인터페이스를 수확하기 위해서는 객체가 어떻게 작업을 수행하는지도 노출해서는 안된다.
의도를 드러내는 인터페이스
- 메서드의 이름을 '어떻게'가 아니라 '무엇'을 하는지 드러내게 작명하라
- '어떻게' 수행하는지 드러내는 이름이란, 메서드의 내부 구현을 설명하는 이름이다.
- 동일한 작업을 수행하는 메서드들을 하나의 타입 계층(역할)으로 묶어서 관리하라
객체에게 묻지 말고 시키되 구현 방법이 아닌 클라이언트의 의도를 드러내야 한다. 이것이 이해하기 쉽고 유연한 동시에 협력적인 객체를 만드는 가장 기본적인 요구사항이다.
우리는 결합도가 낮으면서도 의도를 명확히 드러내는 간결한 협력을 원한다. 디미터 법칙과 묻지 말고 시켜라 스타일, 의도를 드러내는 인터페이스가 우리를 도울 것이다.
