[오브젝트] 15일차

p.186 ~ p.197

디미터 법칙의 위반 → 메시지 전송자가 수신자의 내부 구조에 대해 물어보고 반환 받은 요소에 대해 연쇄적으로 메시지를 전송하는 것 : 기차 충돌

디미터의 법칙을 따르도록 개선된 코드에서 메시지 전송자는 수신자의 내부 구조에 대해 묻지 않고 원하는 것을 명시하고 수행하도록 요청할 뿐이다.

하지만 무비판적인 디미터 법칙의 수용은 퍼블릭 인터페이스 관점에서 객체의 응집도가 낮아질 수 있다.

묻지 말고 시켜라

디미터의 법칙에서 훌륭한 메시지는 객체의 상태에 관해 묻지 않고 원하는 것을 시켜야 한다.

메시지 전송자는 수신자의 상태를 기반으로 결정을 내린 후 수신자의 상태를 바꿔서는 안된다.

단순히 객체를 묻지 않는다고 문제가 해결되는 것은 아니다.

의도를 드러내는 인터페이스

켄트 백이 제시하는 메서드를 명명하는 두 가지 방법이 있다.

1. 메서드가 작업을 어떻게 수행하는지를 나타내도록 이름 짓는 것이다.
   이 경우 메서드의 내부 구현 방법을 드러내도록 이름을 짓는다.
2. 어떻게가 아니라 무엇을 하는지 드러내도록 이름 짓는 것이다.
   무엇을 하는지 드러내는 이름을 유연한 코드를 낳는다. → 객체가 협력 안에서 수행해야 하는 책임에 관해 고민하는 것이고 결과적으로 협력의 관점에서 메서드를 작성하도록 한다.

자바 같은 정적 타이핑 언어에서 단순히 메서드 이름이 같다고 동일한 메시지를 처리할 수는 없다. 따라서 두 메서드를 가진 객체를 동일한 타입으로 간주할 수 있도록 동일한 타입 계층으로 묶는다.

어떻게 하는지가 아닌 무엇을 하느냐에 따라 메서드의 이름을 짓는 패턴을 의도를 드러내는 선택자(Intention Revealing Selector)라고 한다. → 구현과 관련된 모든 정보를 캡슐화하고 객체의 퍼블릭 인터페이스에는 협력과 관련된 의도만을 표현해야 한다.

켄트 벡은 수행방법에 관해서는 언급하지 말고 결과와 목적만을 포함하도록 클래스와 오퍼레이션의 이름을 부여하라고 말한다.

함께 모으기

디미터 법칙에 따르면 인자로 전달된 변수와 인스턴스 변수에 메시지를 전송하는 것은 문제가 없지만, 그 변수의 내부에 포함된 객체에도 직접 접근하는 것은 디미터 법칙을 위반하는 것이다.

근본적으로 디미터 법칙을 위반하는 설계는 인터페이스와 구현의 분리 원칙을 위반한다. 객체의 내부 구조는 구현에 해당한다. → 작은 요구 사항 변경에도 쉽게 무너지는 불안정한 코드를 얻게 된다.

디미터 법칙을 위반한 코드를 수정하는 일반적인 방법은 내부 구조를 묻는 대신 직접 자신의 책임을 수행하도록 시키는 것이다.

디미터 법칙과 묻지 말고 시켜라 스타일을 따르면 자연스럽게 자율적인 객체로 구성된 유연한 협력을 얻게 된다.

오퍼레이션의 이름은 협력이라는 문맥을 반영해야 한다. 따라서 클라이언트가 객체에게 무엇을 원하는지를 표현해야 한다. → 클라이언트의 의도를 표현하는 이름을 가져야 한다.