메시지와 인터페이스

메시지와 메시지 전송

메시지 : 객체들이 협력하기 위해 사용할 수 있는 유일한 의사소통 수단

메시지 전송, 메시지 패싱 : 다른 객체에게 도움을 요청 하는 것

메시지 전송자 : 메시지를 전송하는 객체

메시지 수신자 : 메시지를 수신하는 객체

메시지는 오퍼레이션명과 인자로 구성되며 메시지 전송은 여기에 메시지 수신자를 추가한 것

메시지와 메서드

메서드 : 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저

메시지와 메서드의 구분은 메시지 전송자와 메시지 수신자가 느슨하게 결합될 수 있게 한다.

 - 실행 시점에 메시지와 메서드를 바인딩하는 메커니즘은 두 객체 사이의 결합도를 낮춤으로써 유연하고 확장 가능한 코드를 작성할 수 있게 만든다.

퍼블릭 인터페이스와 오퍼레이션

퍼블릭 인터페이스 : 객체가 의사소통을 위해 외부에 공개하는 메시지의 집합

오퍼레이션 : 퍼블릭 인터페이스에 포함된 메시지

 - 수행 가능한 어떤 행동에 대한 추상화. 흔히 내부의 구현 코드는 제외하고 단순히 메시지와 관련된 시그니처를 가리키는 경우가 대부분이다.

시그니처

오퍼레이션(또는 메서드)의 이름과 파라미터 목록을 합쳐 부르는 것

오퍼레이션 : 실행 코드 없이 시그니처만을 정의한 것

메서드 : 시그니처에 구현을 더한 것

다형성의 축복을 받기 위해서는 하나의 오퍼레이션에 대해 다양한 메서드를 구현해야만 한다.

퍼블릭 인터페이스의 품질에 영향을 미치는 원칙과 기법

디미터 법칙(Law of Demeter)

 - 객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한하는 것

 - 낯선 자에게 말하지 말라(don't talk to strangers)

 - 오직 인접한 이웃하고만 말해라(only talk to your immediate neighbors)

 - 오직 하나의 도트만 사용하라(use only one dot)

    - 하나 이상의 도트를 사용하더라도 객체의 내부 구현에 대한 어떤 정보도 외부로 노출하지 않으면 디미터 법칙 위반이 아니다.

 - 클래스가 특정한 조건을 만족하는 대상에게만 메시지를 전송

    - this 객체

    - 메서드의 매개변수

    - this의 속성

    - this의 속성인 컬렉션의 요소

    - 메서드 내에서 생성된 지역 객체

 - 협력하는 클래스의 캡슐화를 지키기 위해 접근해야 하는 요소를 제한

 - 디미터 법칙을 위반하는 설계는 인터페이스와 구현의 분리 원칙을 위반한다.

 - 객체는 내부 구조를 숨겨야 하므로 디미터 법칙을 따르는 것이 좋지만, 자료 구조라면 당연히 내부를 노출해야 하므로 디미터 법칙을 적용할 필요가 없다.

묻지 말고 시켜라(Tell, Don't Ask)

 - 객체의 상태에 관해 묻지 말고 원하는 것을 시키는 것

 - 객체의 정보를 이용하는 행동을 객체의 외부가 아닌 내부에 위치시키기 때문에 자연스럽게 정보와 행동을 동일한 클래스 안에 두게 된다.

 - 묻지 말고 시켜라 원칙에 따르도록 메시지를 결정하다 보면 자연스럽게 정보 전문가에게 책임을 할당하게 되고 높은 응집도를 가진 클래스를 얻을 확률이 높아진다.

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

 - 메서드가 작업을 어떻게 수행하는지를 나타내도록 이름 짓는다.

 - '어떻게'가 아니라 '무엇'을 하는지를 드러낸다. -> 의도를 드러내는 선택자

 - 구현과 관련된 모든 정보를 캡슐화하고 객체의 퍼블릭 인터페이스에는 협력과 관련된 의도만을 표현해야 한다.

명령-쿼리 분리 원칙(Command-Query Separation)

 - 명령-쿼리 인터페이스(Command-Query Interface) : 명령-쿼리 분리 원칙에 따라 작성된 객체의 인터페이스

 - 루틴(routine) : 어떤 절차를 묶어 호출 가능하도록 이름을 부여한 기능 모듈

 - 프로시저(procedure) : 부수효과를 발생시킬 수 있지만 값을 반환할 수 없다.

    = 명령(Command) : 객체를 상태를 변경. 반환값을 가질 수 없음

 - 함수(function) : 값을 반환할 수 있지만 부수효과를 발생시킬 수 없다.

    = 쿼리(Query) : 객체의 정보를 반환. 상태를 변경할 수 없음

 - 명령과 쿼리를 엄격하게 분류하면 객체의 부수효과를 제어하기가 수월해진다.

    - 참조 투명성(referential transparency)의 장점을 제한적이나마 누릴 수 있게 된다.

책임에 초점을 맞춰라

메시지를 먼저 선택하고 그 후에 메시지를 처리할 객체를 선택하자

객체의 구현 이전에 객체 사이의 협력에 초점을 맞추고 협력 방식을 단순하고 유연하게 만들자

훌륭한 메시지를 얻기 위한 출발점은 책임 주도 설계 원칙을 따르는 것이다.