훌륭한 객체지향 코드를 위해서는 협력 안에서 객체가 수행하는 책임에 초점ㅇ르 맞춰야 하고, 책임이 객체가 수신할 수 있는 메시지의 기반이 된다는 것
클래스가 아니라 객체가 서로 주고받는 메시지를 메인으로 생각하고, 상호작용을 생각해야 좋다
객체는 수신하는 메세지들이 객체의 퍼블릭 인터페이스를 구성한다.
협력과 메시지의 기본적인 개념
협력은 객체가 다른 객체에게 무언가를 요청할 때 시작된다.
아주 전통적인 메타포는 클라이언트-서버 모델.
객체들을 기준으로 봤을 때
객체는 클라이언트, 서버의 역할을 동시에 합니다. 더 큰 책임을 가진 곳이 클라이언트, 작은 책임은 서버의 역할을 하는 경우가 많습니다
객체가 수신하는 메세지 집합, 객체가 전송하는 메시지 집합
베시지는 협력하기 위해 사용할 수 있는 유일한 의사소통 수단
메시지 전송, 메시지 패싱: 다른 객체에게 도움을 요청하는 것
메시지 전송자: 메시지를 전송하는 객체 => 클라이언트
메시지 수신자: 메시지를 수신하는 객체 => 서버
메시지=오퍼레이션명+ 인자
메시지 전송= 메시지 + 수신자
isSatisfiedBy(screening) 이 메시지를 의미하고, condition.isSatisfiedBy(screening) 이 메시지 전송을 의미한다
메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저를 메서드라고 한다
메시지 전송을 코드상에 표기하는 시점에는 어떤 코드가 실행될 것인지를 확인할 방법이 없다. 객체가 존재하고, 그 객체가 적절한 메서드를 선택할 수 있을 것이라고 믿는 것일 뿐이다.
객체들로 구성된 시스템 안에 행동은 메시지, 메서드 2가지로 표현된다
메시지와 메서드로 분리하고, 실행시간에 수신자에 기반해 메시지를 메서드에 바인딩 하는 것은 큰 차이가 된다.
퍼블릭 인터페이스와 오퍼레이션.
객체가 의사소통을 위해 외부에 공개하는 메시지의 집합을 퍼블릭 인터페이스라고 한다.
인터페이스에 포함된 메시지를 오퍼레이션이라고 부른다.
행동에 대한 추상화. 내부 구현 코드 대신, 메시지와, 시그니처만을 설명한다. isSatisfiedBy가 오퍼레이션을 말한다.
실제 정의된 코드는 메서드.
퍼블릭 인터페이스를 호출한다고 생각했을 때는 오퍼레이션 호출쪽이 더 적절하다
오퍼레이션이름+파라미터= 시그니처
디미터 법칙, 묻지말고 시켜라, 의도를 드러내는 인터페이스, 명령-쿼리 분석
디미터의 법칙: 내부 구조에 강하게 결합되지 않도록 제한하는 것
모든 클래스 C와, C가 구현된 모든 메서드 M에 대해서 M이 메시지를 전송할 수 있는 모든 객체는 조건을 만족해야 한다.
M에 의해 생성된 객체, M이 호출하는 메서드에 의해 생성되는 경우는 모두 M의 인자로 계산한다
M의 인자로 전달된 클래스(C자체를 포함), C의 인스턴스 변수의 클래스
this객체, 메서드의 매개변수, this속성, this의 속성인 컬렉션 요소, 메서드 내에서 생성된 지역객체
까지만 전송해야 한다.
기차 충돌: getter로 뽑힌 것을 통해 참조가 발생하는 것
수신자에게 무언가를 시키려는 메시지가 좋은 메시지
묻지 말고 시켜라
상태를 묻는 것이 아닌, 상태를 통해 계산하도록 시킬 뿐. 전송자가 수신자의 상태를 바꾸면 안된다.
인터페이스 분리 원칙이란 객체는 자신이 호출하지 않는 메소드에 의존하지 않아야한다는 원칙이다
디미터 법칙은 하나의 도트를 강제하는 것이 아니다
명령, 쿼리 분리 원칙
어떤 절차를 묶어 호출할 수 있도록 한 것 : 루틴
프로시저 : 부수효과 있지만, void
함수: 부수효과 없고, can return
명령, 쿼리는 함수와 프로시저를 일컫는 다른 말이다.
질문이 답변을 수정해서는 안된다
반복일정의 명령과 쿼리 분리하기
참조 투명성 : 순수 함수
디미터 법칙: 메시지를 먼저 결정해라
묻지 말고 시켜라: 협력을 구조화 한다.
의도를 드러내는 인터페이스 : 전송하는 클라이언트의 입장에서 메시지의 이름을 정한다.
명령-쿼리 분리 원칙: 문맥 안에서 객체의 인터페이스에 관해 고민한다
계약에 의한 설계
