- 스터디 중 삼색볼펜법으로 체크한 부분들을 팀원들과 공유한 내용입니다.
- 스터디원들이 2명 이상 겹치는 부분은 강조표시(BOLD)가 되어 있습니다.
- 문장은 페이지의 오름차순으로 정렬되어 있습니다.
- 원칙을 아는 것보다 더 중요한 것은 언제 원칙이 유용하고 언제 유용하지 않은지를 판단할 수 있는 능력을 기르는 것이다.(198)
- 객체의 상태를 변경하는 명령은 반환값을 가질 수 없다. 객체의 정보를 반환하는 쿼리는 상태를 변경할 수 없다.(203)
- 애플리케이션은 클래스로 구성되지만 메시지를 통해 정의된다는 사실을 기억하라(175)
- 따라서 메시지 전송은 메시지 수신자, 오퍼레이션명, 인자의 조합이다.(177)
- 반면 객체는 메시지와 메소드라는 두 가지 서로 다른 개념을 실행 시점에 연결해야 하기 때문에 컴파일 시점과 실행 시점의 의미가 달라질 수 있다.(178)
- 오퍼레이션은 실행 코드 없이 시그니처만을 정의한 것이다.(180)
- 디미터 법칙을 간단하게 요약하면 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라는 것이다.(183)
- 디미터 법칙을 따르는 코드는 메시지 수신자의 내부 구조가 전송자에게 노출되지 않으며, 메시지 전송자는 수신자의 내부 구현에 결합되지 않는다.(185)
- 디미터 법칙은 훌륭한 메시지는 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다는 사실을 강조한다.(186)
- 상태를 묻는 오퍼레이션을 행동을 요청하는 오퍼레이션으로 대체함으로써 인터페이스를 향상시켜라(187)
- 묻지 말고 시켜라 원칙을 따르면 객체의 정보를 이용하는 행동을 객체의 외부가 아닌 내부에 위치시키기 때문에 자연스럽게 정보와 행동을 동일한 클래스 안에 두게 된다.(187)
- 다시 말해 객체 자신이 아닌 클라이언트의 의도를 표현하는 이름을 가져야 한다.(197)
- 의도를 드러내는 인터페이스 원칙은 객체의 퍼블릭 인터페이스에 어떤 이름이 드러나야 하는지에 대한 지침을 제공함으로써 코드의 목적을 명확하게 커뮤니케이션할 수 있게 해준다.(197)
- 원칙이 현재 상황에 부적합하다고 판단된다면 과감하게 원칙을 무시하라(198)
- 과연 여러 개의 도트를 사용한 코드가 객체의 내부 구조를 노출하고 있는가?(199)
- 객체는 내부 구조를 숨겨야 하므로 디미터 법칙을 따르는 것이 좋지만 자료 구조라면 당연히 내부를 노출해야 하므로 디미터 법칙을 적용할 필요가 없다.(202)
- 명령과 쿼리를 뒤섞으면 실행 결과를 예측하기 어려워질 수 있다.(209)
- 참조 투명성이란 "어떤 표현식 e가 있을 때 모든 e를 e의 값으로 바꾸더라도 결과가 달라지지 않는 특성"이라는 점을 기억하라.(212)
- 훌륭한 메시지를 얻기 위한 출발점은 책임 주도 설계 원칙을 따르는 것이다.(214)
- Movie의 예에서 알 수 있는 것처럼 객체는 협력에 참여하는 동안 클라이언트와 서버의 역할을 동시에 수행하는 것이 일반적이다.(177)
- 실행 시점에 메시지와 메소드를 바인딩하는 메커니즘은 두 객체 사이의 결합도를 낮춤으로써 유연하고 확장 가능한 코드를 작성할 수 있게 만든다.(179)
- 하지만 무비판적으로 디미터 법칙을 수용하면 퍼블릭 인터페이스 관점에서 객체의 응집도가 낮아질 수도 있다.(186)
- 인터페이스는 객체가 어떻게 하는지가 아니라 무엇을 하는지를 서술해야 한다.(187)
- 법칙에는 예외가 없지만 원칙에는 예외가 넘쳐난다.(198)
- 디미터 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다.(198)