# 06장 메시지와 인터페이스

조영호 저 "오브젝트: 코드로 이해하는 객체지향 설계, 2019"를 읽고 정리한 내용입니다.

협력과 메시지

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/8e1a439a-7afb-4500-b4c8-23d03e183a9d/Untitled.png

메시지 : 객체들이 협력하기 위해 사용할 수 있는 의사소통 수단, 오퍼레이션 네임과 인자로 구성됨, 메시지 전송(패싱) : 한 객체(클라이언트)가 다른 객체에게 도움을 요청하는 것, 메시지에 수신자를 추가한 것 메서드 : 메시지를 수신했을 때 실제로 실행되는 함수 또는 프로시저 퍼블릭 인터페이션 : 객체가 의사소통을 위해 외부에 공개하는 메시지의 집합 시그니처 : 오퍼레이션의 이름과 파라미터 목록을 합쳐 놓은 것

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/f48b1660-2de2-4852-ab99-c348a75f4690/Untitled.png

receiver.operation(arguments)

좋은 인터페이스 = 최소한(=꼭 필요한 오퍼레이션 만을 포함) + 추상적인(무엇을 하는지를 표현) 인터페이스, 책임 주도 설계 방법을 따르면 해결 가능

• 디미터 법칙

• 묻지 말고 시켜라

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

• 명령 - 쿼리 분석

디미터 법칙(Law of Demeter)

객체의 내부 구조에 강하게 결합되지 않도록 협력 경로를 제한 하라는 것, don't talk to stanger 패턴, 오직 하나의 .만 사용하라,

자기 소유의 장난감, 자기가 만든 장난감, 그리고 누군가 자기에게 준 장난감하고만 놀 수 있다. 하지만 절대 장난감의 장난감과 놀면 안 된다.

1. this(또는 self) 객체

2. 메소드의 매개변수

3. this의 속성

4. this의 속성인 컬렉션의 요소

5. 메소드 내에서 생성된 객체

public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
	Movie movie = screening.getMovie()

	DiscountCondition = movie.getDiscoutCondition()
	...
	DiscountCondition.getType()
	...
	
	Money fee = // calculdated Fee
	return new reserve(customer, screening, fee, audienceCount)
}

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/44d7f097-78f3-46cf-9161-d47659e14e9a/Untitled.png

public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
	Money fee = screeing.calculateFee(audienceCount)
	return new reserve(customer, screening, fee, audienceCount)
}

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0885320c-adab-40f6-aed0-0bbada2cfd18/Untitled.png

shycode : 디미터 원칙에 따른 코드를 작성하게 되면, 불필요한 어떤 것도 다른 객체에게 노출하지 않는 코드를 작성할 수 있다.

// 디미터 법칙 위반
screening.getMovie().getDiscountCondition();
// 디미터 법칙 준수
screening.calculateFee(audienceCount);

객채의 내부구조에 대해 묻는 것이 아니라 수신자에게 그냥 시키는 것(메시지를 보내는 것) 장려

묻지 말고 시켜라

밀접하게 연관된 정보와 행동을 함께 가지는 객체를 만들 수 있음. 변경될 확률이 높은 정보와 행동을 하나의 클래스 안에 있게 통합 → 메시지 송신시 정보전문가(해당 객체)에 책임을 할당 → 높은 응집도를 가진 클래스 만들어짐

따라서 내부의 상태를 이용해서 어떠한 결정을 내리는 부분이 인터페이스에 노출되지 않게 해야함

// bad
if (customenr.getBag().hasInvitation()){
...
}

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

public class PeriodCondition{
  public boolean isSatisfedByPeriod(Screening screening) {...}
}

public class SequenceCondition{
  public boolean isSatisfedBySequence(Screening screening) {...}
}

문제점

1. 두 클래스의 메서드의 이름이 다르기 때문에, 두 메서드가 같은 행동을 하는 것을 알 수 없음

2. 캡슐화 위반, 클라이언트로 하여금 협력하는 객체에 대해 알 게 함.

public interface DiscountCondition{
    public boolean isSatisfied(Screening screening);
}

//implements
public class PeriodCondition implements DiscountCondition{
  public boolean isSatisfedBy(Screening screening) {...}
}

이처럼 어떻게 하느냐가 아니라 무엇을 하느냐에 따라 메서드 이름 짓는 패턴을 켄트백은 의도를 드러내는 선택자 라고 한다. 에릭 에반스는 도메인 주도 설계에서 의도를 드러내는 선택자 를 인터페이스 레벨로 확장한 의도를 드러내는 인터페이스” 를 제시함.

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/a7313d95-da47-40f9-a2f5-3530b04ca3db/Untitled.png

디미터 법칙에 따르면, Teahter가 인자로 받은 audience와 ticketSeller에게 메시지를 보내는 것은 👍

Ticket ticket = ticketSeller.getTicketOffice().getTicket()

이렇게 내부의 포함된 객체에 접근하는 것은 기차 충돌의 전형 👎

audience.getBag().minusAmount(ticket.getFee());

Audience 의 퍼블릭 인터페이스 뿐만 아니라, 내부 구조에 대해서도 결합된다.

TicketSeller 의 setTicket(), Audience 의 setTicekt(), Bag 의 setTicket()는 의도가 명확히 드러나지 않은 메서드명

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/c43b6080-14be-4786-8830-e41e97b1fa6e/Untitled.png

각각의 상황에 맞게 의도가 명확히 드러나는 퍼블릭 인터페이스를 갖는 것이 좋음

원칙의 함정

IntStream.of(1,15,20,3,9).filter(x-> x>10).distinct().count();

기차 충돌처럼 보이는 코드라도 객체의 내부 구현에 대해 어떤 정보도 외d부로 노출하고 있지 않으면 그것은 디미터 법칙을 준수한 것이다.

명령-쿼리 분리

• 명령 : 객체의 상태를 수정하는 오퍼레이션 (= 프로시저)

• 쿼리 : 객체와 관련된 정보를 반환하는 오퍼레이션 (= 함수)

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/0862c7c5-3210-4a1b-83ee-0c5248dfc560/Untitled.png

동그란 버튼 : 쿼리 메소드 → 값을 알 수 있지만, 어떤 값도 변화시키지 않음

네모난 버튼 : 명령 메소드 → 값을 변화시키지만, 어떤 값도 출력하지 않음

참조 투명성 : 명령과 쿼리를 분리하면, 객체의 부수효과를 제어하기가 수월해짐, 쿼리에는 명령이 개입되지 않기에, 동일한 결과 값을 예측할 수 있고, 명령만을 통해서 객체의 상태를 변하게 함

f(1) + f(1) = 6 ===> 3 + 3 = 6
f(1) * 2 = 6 ===> 3 * 2 = 6
f(1) - 1 = 2 ===> 3 - 1 = 2

책임에 초점을 맞춰라

https://s3-us-west-2.amazonaws.com/secure.notion-static.com/2c392a26-56d2-4510-80a4-5f0e9150fed6/Untitled.png

1. 디미터 법칙을을 준수하고, 묻지 말고 시켜라 스타일을 따르며, 의도를 드러내는 인터페이스를 설계하는 방법은 메세지를 선택하고 그 후에 메세지를 처리할 객체를 선택하는 것이다.

2. 명령과 쿼리를 분리하고, 계약에 의한 설계 개념을 통해 객체의 협력 방식을 명시적으로 드러내는 방법은 객체 구현 이전에 객체 사이의 협력에 초점을 맞추는 것이다.

이 모든 방식의 중심에는 객체가 수행할 책임이 있다.