[오브젝트] 14일차. 172-185pg | 메시지, 메시지 전송, 메소드, 오퍼레이션, 디미터 법칙, 샤이코드

 

 

14일차.

 
오브젝트: 코드로 이해하는 객체지향 설계[3주차_화요일]
172-185pg
 
 

#요약 

 **Chapter 05. 책임 할당하기** 

- 책임에 초점을 맞춰서 설계할 때는 어떤 객체에 어떤 책임을 할당할지 결정하기가 쉽지 않다.

- 책임 할당 과정은 일종의 트레이드오프 활동

- GRASP 패턴은 책임 할당의 어려움을 해결하기 위한 답을 제시해줄 것.

 

01. 책임 주도 설계를 향해

02. 책임 할당을 위한 GRASP 패턴

03. 구현을 통한 검증

04. 책임 주도 설계의 대안

1) 메서드 응집도

2) 객체를 자율적으로 만들자

- 어떤 메소드를 어떤 클래스로 이동? 메소드가 사용하는 데이터를 저장하고 있는 클래스로 메서드를 이동시킨다.

- 데이터를 사용하는 메서드를 데이터를 가진 클래스로 이동시키고 나면 캡슐화와 높은 응집도, 낮은 결합도를 가지는 설계를 얻게 된다.

 

 

 **Chapter 06. 메시지와 인터페이스** 

- 클래스라는 구현 도구에 지나치게 집착하면 경직되고 유연하지 못한 설계에 이르게 된다.

- 협력 안에서는 객체가 수행하는 책임에 초점을 맞춰야 하는데, 책임이 객체가 수신할 수 있는 메시지의 기반이 된다.

- 애플리케이션은 클래스로 구성되지만 메세지를 통해 정의된다.

 

01. 협력과 메세지

1) 클라이언트-서버 모델

- 협력은 어떤 객체가 다른 객체에게 무언가를 요청할 때 시작된다.

- 메세지는 객체 사이의 협력을 가능하게 하는 매개체

- 메시지를 매개로 하는 요청과 응답의 조합이 두 객체 사이의 협력을 구성한다. 

- 협력안에서 메시지를 전송하는 객채 : 클라이언트

- 메시지를 수신하는 객채 : 서버

 

2) 메시지와 메시지 전송

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

- 메시지 전송(message sending), 메시지 패싱(message passing) : 한 객체가 다른 객체에게 도움을 요청하는 것.

- 메시지 전송자(message sender) : 메시지를 전송하는 객체

- 메시지 수신자(message receiver) : 메시지를 수신하는 객체

- 클라이언트-서버 모델 관점에서는 메시지 전송자는 클라이언트, 메시지 수신자는 서버라고 부른다.

- 메시지는 오퍼레이션명(operation name)과 인자(argument)로 구성되며 메세지 전송 = 오퍼레이션 명 + 인자 + 메세지 수신자

 

3) 메시지와 메서드

- method : 메시지를 받았을 때 실제 실행되는 함수 또는 프로시저

- 코드 상에서 동일한 이름의 변수에게 동일한 메시지를 전송하더라도 객체의 타입에 따라 실행되는 메서드가 달라질 수있다는 것이다.

- 객체는 메세지와 메소드라는 두 가지 서로 다른 개념을 샐행 시점에 연결해야 하기 때문에 컴파일 시점과 실행 시점의 의미가 달라질 수 있다.

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

 

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

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

- 오퍼레이션(operation) : 프로그래밍 언어의 관점에서 퍼블릭 인터페이스에 포함된 메시지, 수행 가능한 어떤 행동에 대한 추상화

- 퍼블릭 인터페이스와 메세지의 관점에서는 '메서드 호출'은 '오퍼레이션 호출'이다.

 

5) 시그니쳐

- 시그니쳐(signature) : 오퍼레이션(또는 메소드)의 이름 + 파라미터 목록

- 오퍼레이션은 실행코드 없이 시그니쳐만을 정의한 것이다.

- 오퍼레이션 관점에서 다형성 : 동일한 오퍼레이션 호출에 대해 서로 다른 메서드들이 실행되는 것.

- 객체가 수신할 수 있는 메시지가 객체의 퍼블릭 인터페이스와 그 안에 포함될 오퍼레이션을 결정한다.

- 객체의 퍼블릭 인터페이스가 객체의 품질을 결정 -> 결국 메시지가 객체의 품질을 결정

 

 

 

02. 인터페이스와 설계품질

- 좋은 인터페이스는 최소한의 인터페이스와 추상적인 인터페이스라는 조건을 만족해야 함.

- 최소한의 인터페이스 : 꼭 필요한 오퍼레이션만 인터페이스에 포함

- 추상적인 인터페이스 : 어떻게 수행하는지가 아니라 무엇을 하는지를 표현

=> 가장 좋은 방법은 책임 주도 설계 방법을 따르는 것.

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

   a. 디미터 법칙

   b. 묻지말고 시켜라

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

   d. 명령-쿼리 분리

 

1) 디미터 법칙

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

- "낯선 자에게 말하지 말라", "인접한 이웃과만 말하라"

- 클래스가 특정 조건을 만족하는 대상에게만 메시지를 전송하도록 프로그래밍해야 한다.

- 디미터 법칙을 따르면 부끄럼 타는 코드(shy code)를 작성할 수 있는데,

- 부끄럼 타는 코드(shy code) : 불필요한 어떤 것도 다른 객체에게 보여주지 않고, 다른 객체의 구현에 의존하지 않는 코드

- 디미터 법칙은 캡슐화를 다른 관점에서 표현한 것. 클래스를 캡슐화하기 위해 따라야 하는 구체적인 지침을 제공한다.