오브젝트 (2)

이 포스팅은 오브젝트(조영호)를 읽으면서 정리한 글입니다

이전 포스팅

오브젝트 (1)

---

메시지와 인터페이스

클래스가 아닌 객체(객체가 수행하는 책임)를 지향하라

메시지

애플리케이션은 객체가 주고 받는 메시지로 구성된다.
객체 사이의 협력을 가능케 하려면 메시지를 전송해야 한다.

클라이언트 - 서버 모델

객체 사이의 협력을 나타내는 전통메타포

• 클라이언트 : 메시지를 전송
• 서버 : 메시지를 수신

ex)
Movie가 할인을 적용받고자 하면 Discount policy가 필요해 메시지를 전송하게 된다.
즉 Movie는 클라이언트, Discount policy는 서버라고 볼수있다

메시지 전송(패싱)

객체 → 객체로 도움 요청
- 메시지 전송자 : 메시지 전송 객체
- 메시지 수신자 : 메시지 수신 객체
- operation(오퍼레이션명), argument(인자)로 구성

메신저 전송시에는 메시지 수신자를 포함한다.

ex)
isSatisfied(screening): 메시지
condition.isSatisfied(screening): 메시지 전송 [수신자]+ [오퍼레이션명] + [인자] 로 구성된다.

메시지 전송(Message Passing)은 메서드 호출(Method Call)에 비해 메시지 전송자 / 수신자의 느슨한 결합을 유도한다.

오퍼레이션

수행 가능한 행동에 대한 추상화

클라이언트가 오퍼레이션을 호출하면, 서버의 구체적인 메서드가 실행된다

시그니처

오퍼레이션 이름과 파라미터 목록을 합친 것

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

좋은 인터페이스는 최소한의 인터페이스 & 추상적인 인터페이스이다
→ 책임주도 설계 방법을 따르도록 하자 

디미터법칙

협력 경로의 제한을 통해 강결합을 방지하자

C클래스 내부 메서드 M는 인자로 전달된 클래스, C클래스, C의 인스턴스 변수의 클래스에만 메시지를 전송할 수 있다

ex) this 객체, 메서드의 매개변수,
this 의 attribute, this 의 attribute collection`<E>` 의 `E`,
메서드 내의 지역 객체

→ 이 결과로 shy code를 만들 수 있다.
screening.getMovie().getDiscountConditions() ➡️ 🚫 기차충돌
screening.calculateFee() ⭕️

묻지 말고 시켜라

• 직접 타고 들어가 상태를 묻지 말자.
• 절차적 코드는 정보를 얻은 후에 결정해야 한다.
• 만약 내부의 상태가 꼭 필요하다면, 어떤 결정을 내리는 로직이 객체 외부에 있지는 않은지 검토해야 한다.

ex)
Reservation Agency → screening 에게 movie에 접근하지 않고 요금 계산을 요청했다. '전문가에게 맡겼다..'

메서드 명명 규칙

• 추상화를 신경쓰자
• 결과 - 목적만 포함하도록 오퍼레이션을 명명하도록 하자.
• 공식을 표현하되 푸는 방법을 제시하지 말라.
• 같은 기능을 하는 메서드여도 어디에 위치했느냐에 따라 의도가 달라질 수 있으니 의도를 명확하게 나타내는 메서드명을 짓자.

ex)
> Bag → hold(ticket)
> Audience → buy(ticket)
> Ticket seller → sellTo(ticket)

명령- 쿼리 분리원칙

오퍼레이션은 명령이거나, 쿼리이거나 둘 중 하나여야 한다
1️⃣ 상태를 변경하는 명령은 반환값 X
2️⃣ 정보를 반환하는 쿼리는 상태변경 X

루틴

어떤 절차를 묶어 호출 가능하도록 이름을 부여

프로시저

정해진 절차에 따라 내부 상태를 변경, 부수효과 O

함수

값을 반환, 부수효과 X

명령

객체의 상태 변경

쿼리

객체의 정보를 반환