출처 : 오브젝트 (조영호 저)
객체가 다른 객체에게 접근할 수 있는 유일한 방법은 메시지를 전송하는 것 뿐이다.
메시지는 객체의 타입에 따라 실행되는 메서드가 달라질 수 있다. 반면 메서드는 코드의 의미가 컴파일 시점과 실행 시점에 동일하다. 메시지와 메서드의 구분은 메시지 전송자와 메시지 수신자가 느슨하게 결합될 수 있게 한다.
메시지 전송자와 메시지 수신자는 서로에 대한 상세한 정보를 알지 못한 채 단지 메시지라는 얇고 가는 끈을 통해 연결된다. 실행 시점에 메시지와 메서드를 바인딩하는 메커니즘은 두 객체 사이의 결합도를 낮춤으로써 유연하고 확장 가능한 코드를 작성할 수 있게 만든다.
디미터 법칙(Law of Demeter)
객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하는 것. “낯선 자에게 말하지 말고, 오직 인접한 이웃하고만 말하라" 라고 요약할 수 있다.
디미터 법칙을 따르기 위해서는 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송하도록 프로그래밍 해야 한다.
- this 객체
- 메서드의 매개변수
- this의 속성
- this의 속성인 컬렉션의 요소
- 메서드 내에서 생성된 지역 객체
디미터 법칙을 따르면 부끄럼 타는 코드(shy code)를 작성할 수 있다. shy code란 불필요한 어떤 것도 다른 객체에게 보여주지 않으며, 다른 객체의 구현에 의존하지 않는 코드를 말한다. 이는 낮은 결합도를 유지할 수 있다.
디미터 법칙은 캡슐화를 다른 관점에서 표현한 것이다. 다음은 디미터 법칙을 위반하는 전형적인 모습이다.
screening.getMovie().getDiscountConditions();디미터 법칙은 객체가 자기 자신을 책임지는 자율적인 존재여야 한다는 사실을 강조한다. 정보를 처리하는 데 필요한 책임을 정보를 알고 있는 객체에게 할당하기 때문에 응집도가 높은 객체가 만들어진다.
근본적으로 디미터 법칙을 위반하는 설계는 인터페이스와 구현의 분리 원칙을 위반한다. 클라이트에게 구현을 노출한다는 것을 의미하며, 그 결과 작은 요구사항 변경에도 쉽게 무너지는 불안정한 코드를 얻게 된다.
묻지 말고 시켜라 (Tell, Don’t Ask)
메시지 전송자는 메시지 수신자의 상태를 기반으로 결정을 내린 후 메시지 수신자의 상태를 바꿔서는 안된다. 이것은 객체의 캡슐화를 위반한다.
이 원칙에 따르다 보면 자연스럽게 정보 전문가에게 책임을 할당하게 되고 높은 응집도를 가진 클래스를 얻을 확률이 높아진다. 이 스타일을 따르지 않을 경우 기차충돌(train wreck)으로 알려진, 일련의 getter들이 기차의 객차처럼 상호 연결되어 보이는 코드가 만들어지고 만다.
디미터 법칙을 위반한 코드를 수정하는 일반적인 방법은 내부 구조에 관해 묻지 말고 원하는 작업을 시켜야 한다.
의도를 드러내는 인터페이스
메서드의 이름을 짓는 방법은 ‘어떻게'가 아니라 ‘무엇'을 하는지를 드러내는 것이며, 수행 방법에 관해서는 언급하지 말고 결과와 목적만을 포함하도록 이름을 부여한다. 이는 클라이언트의 관점에서 동일한 작업을 수행하는 메서드들을 하나의 타입 계층으로 묶을 수 있는 가능성이 커진다. 그 결과, 다양한 타입의 객체가 참여할 수 있는 유연한 협력을 얻게 되는 것이다.
원칙의 함정
디미터 법치과 묻지 말고 시켜라 스타일은 객체의 퍼블릭 인터페이스를 깔끔하고 유연하게 만들 수 있는 훌륭한 설계 원칙이다. 하지만 절대적인 법칙은 아니다. 잊지 말아야 할 사실은 설계가 트레이드 오프의 산물이라는 것이다.
명령 쿼리 분리 원칙
프로시저는 정해진 절차에 따라 내부의 상태를 변경하는 루틴의 한 종류이다. 이에 반해 함수는 어떤 절차에 따라 필요한 값을 계산해서 반환하는 루틴의 한 종류이다.
명령과 쿼리는 객체의 인터페이스 측면에서 프로시저와 함수를 부르는 또 다른 이름이다. 객체의 상태를 수정하는 오퍼레이션은 명령이고, 객체와 관련된 정보를 반환하는 오퍼레이션을 쿼리라고 한다.
어떤 오퍼레이션도 명령인 동시에 쿼리여서는 안된다. ⇒ “질문이 답변을 수정해서는 안된다.”
명령과 쿼리를 뒤섞으면 실행 결과를 예측하기가 어려워질 수 있다.
