객체지향의 사실과 오해 3

훌륭한 메시지가 훌륭한 객체지향 설계의 기반임을 강조 

객체의 자율성과 설계의 유연성은 어떤 메시지를 선택하느냐에 달렸다.

 

5. 책임과 메시지

 

5.1 자율적인 책임

> 설계의 품질을 좌우하는 책임 

   - 기능 구현을 위해 협력하고 그 과정에서 책임을 다하기 위해 자율적 행동

   - 객체가 어떤 행동을 하는 유일한 이유는 메시지의 수신 (책임)

> 자신의 의지에 따라 증언할 수 있는 자유

   - 재판하라는 메시지에 자율적 책임을 다함 

   - 메시지 송신자는 어떤 방식으로 응답하는지는 관심이 없다.

   - 어떤 메시지를 전하는냐에 따라 자율성을 침해할 여지가 있다.

   - 충분히 자율적이기 위해선, 책임이 추상적일 필요가 있다(메시지가) 

> 너무 추상적인 책임

   - 협력의 의도를 명확하게 표현하지 않는 것도 문제

   - 너무 과도한 자율성은 협력을 깨뜨릴 수 있다.

   - 따라서 충분히 추상적이면서 협력의 의도를 드러내는 책임(메시지)가 필요 

> 어떻게가 아니라 무엇을

> 책임을 자극하는 메시지 

   - 메시지는 책임을 수행하도록 외부에서 전달된 요청 (책임이 먼저 어떤 메시지를 통해서 책임을 수행할 것인가)

 

 

5.2 메시지와 메서드

- 메시지를 전송하여 다른 객체에 접근 

- 증언하라 (메시지이름) 응답에 필요한 추가정보 -> 인자 증언하라(어제,왕국)

- 수신자까지 합쳐서 모자장수.증언하라(어제,왕국) 

- 메시지를 처리한다 -> 메시지에 해당하는 행동을 수행할 책임이 있다. 

 

* 객체가 서로 협력하기 위해 사용하는 수단 -> 메시지 

   메시지 수신 가능 -> 객체가 해당 책임을 수행할 수 있다는 것

   외부 객체는 메시지만 볼 수 있고, 자율적 책임 수행 방식은 볼 수 없다. 

  > 책임은 한쪽 객체의 관점 - 다른 객체 존재 여부에 상관 없이 외부에 제공할 수 있는 행위

      메시지는 송신자 수신자, 객체 간 상호 협력의 문맥 강조 

      - 한 객체는 메시지를 송신할 수 있고 다른 객체는 이를 수신하여 책임을 수행할 수 있음을 보는 것 

      - 메시지와 책임의 수준은 같지 않음, 책임은 객체가 협력에 참여하기 위해 수행해야하는 행위를 상위 수준에서 서술 

      - 책임이 결정된 후 실제로 협력하면서 메시지로 변환되면, 하나의 책임은 여러 메시지로 분할 

 

        (왕 -> 증언하라 -> 모자장수), (토끼 -> 증언하라 -> 모자장수) -> 모자장수 증언의 책임이 메시지로 변환  

 

> 메서드 

   - 메시지 처리를 위해 선택할 수 있는 방법 (내부, 자율 선택)

 > 다형성 

    - 메시지와 메서드의 분리 

    - 동일한 메시지에 서로 다른 반응 

    - 서로 다른 타입에 속하는 객체들이 동일한 메시지를 수신할 경우 서로 다른 메서드로 처리 

    - 다형성은 하나의 메시지와 하나 이상의 메서드의 관계이다. 

    - 다형성에서 중요한 것은 송신자의 관점 -> 다형적 수신자 구별할 필요가 없어 요청을 수행할 책임을 지닌다는 점에서 모두 동일 

    - 송신자는 동일 역할 수행하는 다양한 타입의 객체와 협력 (대체 가능성, 수신자의 캡슐화) 

    - 송신자와 수신자 간 객체 타입에 대한 결합도를 메시지에 대한 결합도로 낮춰서 달성 

 

> 유연하고 확장 가능하고 재사용성이 높은 협력의 의미 

   - 송신자는 수신자에 대한 매우 적은 정보만으로 상호 협력이 가능하다.

    1. 협력이 유연해진다.

    2. 협력이 수행되는 방식을 확장할 수 있다.

    3. 협력이 수행되는 방식을 재사용할 수 있다. 

 

> 송신자와 수신자를 약하게 연결시키는 메시지 

   - 다형성을 지탱하는 메시지가 중요 송신자 수신자 사이 결합도를 낮춤 

   - 송신자는 오직 메시지만 바라본다. 수신자의 정확한 타입은 몰라도 된다.

 

5.3 메시지를 따라라 

- 메시지 전송, 메시지 수신 -> 책임 수행 (자율적 방식)

- 클래스는 코드를 구현하기 위해 중요한 추상화 도구, 하지만, 객체지향의 강력함은 메시지로부터 나온다.

- 클래스를 이용해 만들어지지만, 메시지를 통해 정의된다.

- 클래스는 동적 객체의 특성과 행위를 정적 텍스트로 표현하기 위해 사용할 수있는 추상화 도구 

- 객체들의 속성과 행위 식별이 먼저다 

- 메시지를 주고받는 동적 객체들의 집합으로 시스템을 바라보자,

  클래스에 담길 객체들의 공통적인 행위외 속성을 포착하기 위해서 협력하는 객체의 관점에서 시스템을 바라봐야 한다. 

- 객체가 메시지를 선택하는게 아니라, 메시지가 객체를 선택해야함 

 

>책임 주도 설계 다시 보기

- 메시지 기반으로 역할,책임,협력을 발견하는것 

- 시스템 기능을 구현하기 위해 협력 관계를 시작할 적절한 객체를 찾아 책임을 할당해야한다.

- 어떤 메시지가 필요한지 결정하고, 메시지 수신하기에 적합한 객체를 선택한다. (메시지가 책임을 결정)

 

> what/who 사이클 

- 어떤 행위 수행할 것인지 결정한 후에 누가 행위를 수행할 것인지 결정해야한다. 

- 필요한 메시지를 먼저 결정한후 객체를 선책 수신된 메시지가 객체의 책임을 결정 

- 수신 가능한 메시지가 모여 객체의 인터페이스를 구성 (메시지를 결정해야 인터페이스를 발견할 수 있다) 

 

> 묻지말고 시켜라

 - 다른 객체의 상태를 묻지말고, 어떻게가 아니라 무엇을 해야하는지 요청 

 

*정리 객체가 어떤 메시지 수신하고 처리할 수 있는냐가 객체의 책임을 결정, 책임 주도 설계 방법은 what/who 사이클에 따라 협력에 참여할 객체를 결정하기 전에 메시지를 먼저 결정 이후에 수신할 후보를 선택

 

 * 꼭 인터페이스 만들라는게 아니고, 메시지가 인터페이스나,상속과 같은 다형성을 구현할 수 있는 중요한 역할을 수행한다~ 

 

5.4 객체 인터페이스 

> 인터페이스

  - 일반적으로 두 사물이 마주하는 경계 지점에서 서로 상호작용 하도록 이어주는 방법이나 장치 

     ex 텔리비전-리모컨, UI 대상과 상호작요하려면, 인터페이스 사용법을 익혀야함 

  - 인터페이스의 특징

     1. 사용법만 익히면 내부 동작,방식 몰라도 됨

     2. 인터페이스 자체 변경이 아닌 내부 변경은 외부에 영향 없음

     3. 대상이 변경되더라도 동일한 인터페이스 제공하면 문제 없이 작동 

         ex 모든 자동차는 동일한 인터페이스 제공, 하나의 인터페이스에 능숙 -> 어떤 자동차라도 운전 

- 협력에 참여하는 객체도 인터페이스를 통해 가른 객체와 상호작용한다. 

- 메시지가 인터페이스 결정

 

> 공용 인터페이스 

 - 외부에서 접근 가능한 인터페이스 (책임-메시지 한 쌍) 

 - 공용 인터페이스 자극하여 책임을 수행하게 하는 것은 객체에 메시지 

 - 책임은 메시지 수신 시에 수행할 객체의 행동 

 

> 책임,메시지,인터페이스 

  - 협력에 참여하는 객체에 책임은 자율적 (행동,상태등으로 구체화)

  - 객체의 인터페이스는 객체가 수신할 수 있는 메시지 목록으로 채워진다. 

     메시지와 메서드의 구분은 객체의 외부,내부를 분리함과 동시에 다형성을 통해 유연성을 부과한다.

  - 객체가 메시지를 받기위한 통로인 인터페이스 -> 객체간 협력의 접점 -> 객체가 어떤 메시지를 수신할 수 있느냐가 인터페이스 모양 결정 

 

5.5 인터페이스와 구현의 분리 

 

> 객체 관점에서 생각하는 방법

 

  - 좀 더 추상적인 인터페이스 : 자율적 책임, 추상적 수준의 메시지 수신 인터페이스 만들기 

  - 최소 인터페이스 : 외부에 사용할 필요가 없는 인터페이스 감춤, 메시지를 먼저 생각하고 객체를 나중에 생각

  - 인터페이스와 구현 간 차이를 인식 

 

> 구현

 - 객체지향에서 내부 구조와 작동 방식을 가리키는 고유 용어이다.

 - 객체를 구성하지만, 공용 인터페이스에 포함되지 않는 모든 것이 구현에 포함된다.

   (상태, 행동)

 - 외부와 내부를 분리하라는 것은 공용 인터페이스와 구현을 명확하게 분리하라는 것이다. 

 

> 인터페이스와 구현의 분리 원칙 

  - 객체를 두 개의 분리된 요소로 분할해 설계하자 ( 외부와 내부를 나누자)

  - 안전지대(내부) - 위험지대(외부) 나누기 

  - 메서드의 구현이 수정되더라도 외부에 영향을 미쳐서는 안된다. 객체 외부에 영향을 미치는 것은 공용 인터페이스를 수정했을 때 뿐이다. 

 

> 캡슐화

 - 객체의 자율성 보존을 위해 구현을 외부로부터 감추는 것을 의미한다. -> 정보 은닉 

 -> 상태와 행위의 캡슐화

     - 객체는 상태와 행위의 조합, 스스로 상태를 관리 해야한다. 행위와 한쌍 (데이터 캡슐화)

     - 데이터 캡슐화의 전제는 인터페이스와 구현을 분리하는 것 

 -> 사적인 비밀의 캡슐화

     - 외부 객체가 내부 상태를 직접 관찰하거나 제어할 수 없도록 특별한 경로만 외부에 노출하자 (공용 인터페이스)

     - 공용 인터페이스를 경계로 최대한 자율성을 보장받을 수 있다.  

     - 외부 객체는 공용 인터페이스에만 의존해야하고 세부 사항에 직접 의존해선 안됨 

 

* 다시 한번 책임을 결정하는 것은 메시지, 자율적인 책임의 특성은 자율 책임을 수행하게 하는 메시지의 특성과 연결된다.

 

5.6 책임의 자율성이 협력의 품질을 결정한다.

 

- 객체의 책임이 자율적일 수록 협력이 이해하기 쉬워지고 유연하게 변경할 수 있게 된다.

 

1. 자율적인 책임은 협력을 단순하게 만든다. 

    - 충분히 추상적인 메시지를 전달하도록 해서 협력의 과정이 단순해 진다.

2. 자율적인 책임은 객체의 외부와 내부를 명확하게 분리한다.

    - 자율적 책임으로 협력의 양상이 다른 객체와의 외부 협력과 객체 스스로 책임을 수행하는 내부 관점으로 분리된다.

    - 캡슐화가 되기 때문에 인터페이스와 구현이 분리된다. 

3. 자율적인 책임은 내부의 변경이 외부에 영향을 미치지 않는다. 

    - 자율적 책임으로 인해 변경의 파급효과가 객체 내부로 캡슐화되므로, 객체간 결합도가 낮아진다. 

4. 자율적 책임은 협력의 대상을 다양하게 선택할 수 있는 유연성을 제공한다. 

5. 책임이 자율적일 수록 객체의 역할을 이해하기 쉬워진다. 

    - 객체 존재 이유가 명확하게 표현된다. 

    - 객체들은 동일한 목적을 달성하는 강하게 연관된 책임으로 구성되므로, 객체의 응집도를 높은 상태로 유지하기 쉽다.

 

*책임이 자율적일수록 추상화되고, 응집도가 높아지고, 결합도는 낮아지며, 캡슐화가 증진되고, 인터페이스 구현이 분리되며, 설계의 유연성과 재사용성이 향상된다. 

  객체지향의 강력함을 누리기 위한 출발점은 책임을 자율적으로 만드는 것이고, 이는 어떤 메시지를 선택하느냐에 달렸다. 

 

-> 협력의 관계에서 메시지의 강력함은, 

    메시지가   1. 책임을 결정하고, 객체의 자율성 수준을 결정

                    ->  자율적인 객체는 책임을 수행하며 인터페이스와 구현을 분리 : 캡슐화 증진

                    ->  캡슐화 증진으로 내부와 외부가 분리되며 객체 간 결합도가 낮아짐

                      2. 이러한 효과로 메시지를 통해 송신자와 수신자 결합도가 낮아져 다형성이 가능하게 된다 

                         송신자 입장에서는 해당 메시지를 수신해서 결과만 받으면 됨 ( 수신자의 타입, 메시지 처리 방식은 몰라)

                      3. 위 두가지 효과 (캡슐화, 다형성 증진) 객체 역할을 이해하기 쉬워지고, 협력의 과정이 단순해지고, 설계가 유연해짐    

 

 

 

6. 객체 지도 

 

- 객체지향이 구조와 기능이라는 두 관점을 어떻게 조화시키는 지 설명

- 구조는 기능에 비해 더 안정적이다. 객체지향은 구조안에 기능을 녹여서 변화에 안정적인 소프트 웨어를 만들게 한다.

 

6.1 기능 설계 대 구조 설계

6.2 두 가지 재료: 기능과 구조

6.3 안정적인 재료 : 구조

6.4 불안정한 재료 : 기능 

6.5 재료 합치기 : 기능과 구조의 통합