두 객체 사이의 협력 관계를 설명하기 위한 전통적인 메타포
클라이언트가 서버의 서비스를 요청하는 단방향 상호작용
객체는 클라이언트와 서버의 역할을 동시에 수행하는 것이 일반적
두 객체 사이의 협력을 가능하게 해주는 매개체는 메시지
메시지란?
예를 들어, buyWater(money)는 메시지
메시지 수신자인 market을 추가한 market.buyWater(money)이 메시지 전송
객체가 의사소통을 위해 외부에 공개하는 메시지의 집합을 퍼블릭 인터페이스라고 부른다.
퍼블릭 인터페이스에 포함된 메시지를 오퍼레이션이라고 부른다.
-시그니처는 오퍼레이션의 이름과 파라미터 목록을 합쳐서 부르는 용어다.
오퍼레이션은 실행 코드 없이 시그니처만을 정의한 것이다.
객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하라는 법칙
낯선 자에게 말하지 말라
인접한 이웃하고만 말하라
오직 하나의 도트만 사용하라
클래스 내부의 메서드가 아래 조건을 만족하는 인스턴스에만 메시지를 전송하라
this 객체
메서드의 매개변수
this 속성
this의 속성인 컬렉션의 요소
screenig.getMovie().getDiscountConditions()
위코드는 Movie의 메소드까지 알아야 할것을 요구하게된다. 이로 인해 캡슐화는 무너진다.
올바른 코드 :
screenig.calculateFee(audienceCount)
디미터 법칙은 훌륭한 메시지는 객체의 상태에 관해 묻지 말고 원하는 것을 시켜야 한다는 사실을 강조
묻지 말고 시켜라 원칙에 따르도록 메시지를 결정하다 보면 자연스럽게 정보 전문가에게 책임을 할당하고 높은 응집도를 가진 클래스를 얻을 확률이 높아진다.
오퍼레이션의 이름은 협력이라는 문맥을 반영해야 한다.
클라이언트가 객체에게 무엇을 원하는지 명확하게 표현해야 한다.
디미터 법칙은 객체 간 협력을 설계할 때 캡슐화를 위반하는 메시지가 인터페이스에 포함되지 않도록 제한한다.
디미터의 법칙은 하나의 도트(.)를 강제하는 규칙이 아니다.
과연 여러개의 도트를 사용한 코드가 객체의 내부 구조를 노출하고 있는가?
디미터 법칙과 묻지말고 시켜라 법칙을 무작정 따를 필요는 없음
예시) Screening 이 자신이 판단해야하지 않을 다른 책임을 지게되는 경우
객체의 응집도가 낮아질수 있음.
캡슐화 향상시키는것보다 결합도를 낮추는것이 전체적으로 더 나을수 있음.
디미터 법칙의 위반여부는 객체인지 자료구조인지에 달려있음.
자료구조일 경우 당연히 내부를 노출해야하므로 법칙에서 제외
원칙이 필요하고 적절한 상황인지 판단해야함.
명령-쿼리 분리 원칙은 퍼블릭 인터페이스에 오퍼레이션 정의에 가이드를 제공한다. 먼저 프로시저와 함수의 차이를 알아보자.
프로시저 : 부수효과를 발생하지만 값을 반환하지 않는다.
함수 : 값을 반환하지만 부수효과는 없다.
명령과 쿼리는 프로시저와 함수의 또 다른 의미이다. 명령은 객체를 수정하는 오퍼레이션이고, 쿼리는 객체의 정보를 반환하는 오퍼레이션이다.
명령-쿼리 분리 원칙은 오퍼레이션이 객체를 수정하면서 정보를 반환하는 작업을 동시에 하지 말라 는 원칙이다.
한마디로 "질문이 답변을 수정해서는 안된다"는 것이다.