객체지향의 사실과 오해) 05 / 책임과 메시지

모듈 내부의 속성과 행동이 어떤가보다는  모듈이 어떻게 커뮤니케이션 하는가에 집중하라.

-결론은..

1. 송신자는 메시지 먼저 결정하고, 그에 맞는 객체를 찾고, 수신자는(객체)는 메시지를 처리한다.

2. 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 명확하게 분리해야 한다 

객체가 어떻게(how) 해야 하는가가 아니라 무엇(what)을 해야하는 가에 집중해야 한다

" 소프트웨어는 항상 변경된다 "

- 어떤 객체를 수정했을 때 어떤 객체가 영향 받는지를 판단하는 것은 힘들다.

- 외부에 영향을 주지 않고도 메서드를 자유롭게 변경할 수 있어야 한다. 

  따라서 적절한 구현을 선택하고 이를 인터페이스 뒤로 감춰야 한다. 

자율적인 책임

자율적인 객체란 스스로 정한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체

ex) 왕이 모자장수에게 '증언하라'는 요청

- 왕은 모자장수가 어떤 방법으로 증언하는지 신경을 안쓴다

- 모자장수는 왕의 요청을 받아 책임을 수행하긴 하겠지만, 

  증언방식이나 필요자료등은 스스로의 의지와 판단에 따라 자유롭게 선택할 수 있다.

너무 구체적인 책임도 문제지만, 협력의 의도를 명확하게 표현하지 못할 정도로 추상적인 것도 문제다.

ex) 문제가 되는 책임

- 너무 구체적인 책임 : '목격장면을 떠올려라', '시간 순서대로 재구성하라', '말을 간결하게 표현하라' 

- 너무 추상적인 책임 : '설명하라' 

객체가 어떻게(how) 해야 하는가가 아니라 무엇(what)을 해야하는 가에 집중해야 한다

메시지와 메서드

메시지 

모자장수는 '증인석에 입장하라' , '증언하라' 두가지의 메시지를 받고 이를 처리할 방법을 자유롭게 선택할 수 있고, 

왕과 토끼는 메시지를 제외한 어떤 것도 볼 수 없다.

왕은 자신이 어떤 메시지를 전송할 수 있는지와, 모자장수가 어떤 방법이든 자신의 메시지를 처리해줄 것이라는 사실만 알고 있다.

따라서 모자장수가 메시지를 변경하지만 않는다면 책임을 수행하는 방법을 변경하더라도 왕은 그 사실을 알수없다.

(객체의 외부와 내부의 분리)

메서드

자신에게 주어진 책임을 다하기 위해 메시지를 처리할 방법

다형성

- 서로 다른 유형의 객체가 동일한 메시지에 대해 서로 다르게 반응(서로 다른 메서드)하는 것

ex) 요리사, 모자장수, 엘리스는 '증언하라' 메시지를 수신했을 때 각각 어떤 방법을 사용하건 왕의 입장에서는 결과가 동일

- 송신자가 수신자의 종류를 몰라도 메시지를 전송할 수 있음

즉, 다형성은 수신자의 종류를 캡슐화한다.

ex) 왕은 '증언하라' 라는 메시지를 전송하지만, 메시지를 수신하는 대상이 모자장수인지, 요리사인지 알 필요가 없다

왕은 오직 수신자가 메시지를 이해할 수 있다는 사실만 알고 있는 상태에서 협력에 참여

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

송신자가 수신자에 대해 매우 적은 정보만 알고 있더라도 상호 협력이 가능하다는 사실은 설계의 품질에 큰 영향을 미친다.

1. 협력이 유연해진다. 

- 송신자는 수신자가 메시지를 이해한다면 누구라도 상관없다. 

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

- 송신자에게 아무런 영향도 미치지 않고 수신자를 교체할 수 있다

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

- 협력에 영향없이 다양한 객체들이 수신자의 자리를 대체할 수 있다. 

- 재판이라는 협력은 다른 곳에서도 재사용이 가능

메시지를 따라라

객체지향의 핵심, 메시지

- 객체지향의 강력함은 클래스가 아니라 객체들이 주고받는 메시지로 부터 나온다. 

- 객체지향 애플리케이션은 클래스를 이용해 만들어지지만, 메시지를 통해 정의된다. 

객체의 내부구조는 감춰져야 한다. 

외부의 객체가 객체의 내부를 마음대로 할 수 있다면 객체의 자율성이 저해된다. 

책임-주도 설계

- 객체들 간에 주고받는 메시지를 기반으로 적절한 역할과 책임, 협력을 발견하는 것

1. 객체가 책임을 완수하기 위해 다른 객체의 도움이 필요하면 도움을 요청하기 위해 어떤 메시지가 필요한지 결정한다. 

2. 메시지를 결정한 후에는 메시지를 수신하기에 적합한 객체를 선택한다. 

3. 수신자는 송신자가 기대한 대로 메시지를 처리한다. 

즉, 메시지가 수신자의 책임을 결정한다. 

책임주도 설계 관점에서는 

어떤 객체가 어떤 특성을 가지고 있다고 해서 반드시 그와 관련된 행위를 수행할 것이라고 가정하지 않는다. 

반대로 행위를 먼저 식별한 후에 행위를 수행할 적절한 객체를 찾는다. 

What/Who 싸이클

- 어떤 행위(What)(메시지)를 수행할 것인지를 결정한 후에 누가(who)가 그 행위를 수행할 것인가를 결정해야 한다. 

묻지말고 시켜라

- 객체는 다른 객체의 결정에 간섭하지 말아야하며, 모든 객체는 자신의 상태를 기반으로 스스로 결정을 내려야 한다. 

- 메시지가 어떻게 해야하는지를 지시하지 말고 무엇을 해야 하는지를 요청

- 묻지말고 시켜라 스타일은 객체를 자율적으로 만들고, 캡슐화를 보장하며, 겹합도를 낮게 유지시켜준다 

메시지를 믿어라 

객체 인터페이스

인터페이스

- 어떤 두 사물이 마주치는 경계지점에서 서로 상호작용할 수 있게 이어주는 방법이나 장치

특징

ex) 운전자와 자동차사이의 핸들, 변속기, 엑셀, 브레이크 등

1. 인터페이스의 사용법만 알고 있으면 대상의 내부 구조나 동작 방법은 몰라도 상호 작용이 가능하다. 

- 자동차 내부는 몰라도 핸들,변속기 같은 인터페이스를 이용해 운전 가능

2. 단순히 내부 구성이나 작동방식이 변경되는 것은 사용자에게 아무런 영향도 미치지 않는다. 

- 자동차 내부를 변경한다고 해서 운전하는 방법이 변하는 것은 아니다.

3. 인터페이스가 동일하기만 하다면 어떤 대상과도 상호작용할 수 있다. 

- 티볼리 운전자가 모닝도 운전가능

공용 인터페이스

- 공용 인터페이스 : 외부에서 접근 가능한 공개된 인터페이스

- 사적 인터페이스 : 내부에서만 접근 가능한 사적인 인터페이스

책임, 메시지, 그리고 인터페이스

정리

1. 협력에 참여하는 객체의 책임이 자율적이어야 한다. 

2. 메시지, 메서드

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

  그 객체가 메시지를 수신했을 때 적절한 객체의 책임이 수행된다. 

- 메서드는 메시지를 수신했을 대 책임을 수행하는 방법

3. 인터페이스

- 객체가 다른 객체와 협력하기 위한 접점

인터페이스와 구현의 분리

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

1. 좀 더 추상적인 인터페이스

- 세부사항을 제거하고 메시지의 의도를 표현하기 위해 사용한 기법이 추상화

2. 최소 인터페이스

- 외부에서 사용할 필요가 없는 인터페이스는 최대한 노출하지 말라

3. 인터페이스와 구현 간에 차이가 있다는 점을 인식

- 객체의 외부와 내부를 명확하게 분리하는 것 (공용 인터페이스와 구현을 명확하게 분리하라는 말)

- 객체의 외부를 공용 인터페이스라 부르고, 객체의 내부를 가르키는 용어는 구현이다. 

구현

- 객체지향의 세계에서 내부 구조와 작동 방식을 가르키는 고유의 용어는 구현 (implementation)

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

객체의 외부와 내부를 분리하라는 것은 결국 객체의 공용 인터페이스와 구현을 명확하게 분리하라는 말이다.

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

- 훌륭한 객체란 구현을 모른채 인터페이스만 알면 쉽게 상호작용할 수 있는 객체를 의미

- 객체 외부에 노출되는 인터페이스와 객체의 내부에 숨겨지는 구현을 명확하게 분리해서 고려해야 한다

인터페이스와 구현의 분리 원칙이 중요한 이유

" 소프트웨어는 항상 변경되기 때문이다.  "

- 어떤 객체를 수정했을 때 어떤 객체가 영향 받는지를 판단하는 것은 힘들다.

- 외부에 영향을 주지 않고도 메서드를 자유롭게 변경할 수 있어야 한다. 

  따라서 적절한 구현을 선택하고 이를 인터페이스 뒤로 감춰야 한다. 

결론은

객체가 가져야 할 상태와 메서드 구현은 객체 내부에 속하고, 

이부분을 수정하더라도 객체 외부에 영향을 미쳐서는 안된다. 

객체 외부에 영향을 미치는 변경은 객체의 공용 인터페이스를 수정할 때 뿐이다. 

" 인퍼테이스와 구현을 분리한다는 것은 변경될 만한 부분을 객체의 내부에 꽁꽁 숨겨놓는 다는 것을 의미"

캡슐화 

- 객체의 자율성을 보존하기 위해 구현을 외부로부터 감추는 것

- 정보은닉(infomation hiding) 이라고 하기도 함

캡슐화는 두 가지 관점에서 사용됨

1. 상태와 행위의 캡슐화 (데이터 캡슐화)

-  객체는 상태와 행위를 한데 묶은 후 / 외부에서 반드시 접근해야하는 행위만 골라 /공용 인터페이스를 통해 노출한다. 

따라서 데이터캡슐화는 인터페이스와 구현을 분리하기 위한 전제조건

- 상태는 데이터로 구현, 

  행동은 프로세스로 구현된다.  

2. 사적인 비밀의 캡슐화

- 외부의 객체가 자신의 내부상태를 직접 관찰하거나 제어할 수 없도록 막기위해 

  의사소통 가능한 특별한 경로만 외부에 노출한다. 

  이처럼 외부에서 객체와 의사소통 할 수 있는 고정된 경로를 공용 인터페이스라고 한다. 

- 객체는 공용 인터페이스를 경계로 최대한의 자율성을 보장한다. 

- 외부의 객체는 공용 인터페이스에만 의존해야 하고 / 구현 세부 사항에 대해서는 직접적으로 의존해서는 안된다. 

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

- 객체의 책임이 자율적일수록 협력이 이해하기 쉽고 변경에 유연하다.

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

- 모자장수의 자유로운 증언

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

- 왕이 모자장수를 바라보는 외부관점

- 모자 장수가 책임을 수행하는 방법을 표현하는 내부 관점

왕은 모자장수가 외부에 노출한 책임은 볼수 있지만 모자 장수가 내부적으로 어떻게 책임을 수행하는지는 볼수 없다.

3. 책임이 자율적일 경우 책임을 수행하는 내부적인 방법을 변경하더라도 외부에 영향을 미치지 않는다. 

- 왕은 모자장수가 책임을 수행하는 방법에는 관심도 없고 볼수조차 없다.

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

- 왕은 모자장수말고 다른사람이 증언해도 상관없다

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

- 모자장수는 증인석에 입장하는 책임과 증언하는 책임을 자신의 의지를 기반으로 완수할 수 있을 정도로 충분히 자율적이다.