객체지향의 사실과 오해 - 5장(책임과 메시지)

훌륭한 객체지향의 세계는 명확하게 정의된 역할과 책임을 지닌 객체들이 상호협력하는 세계

 

자율적인 책임

"자율적인 객체"

스스로 적한 원칙에 따라 판단하고 스스로의 의지를 기반으로 행동하는 객체로 스스로의 판단에 따라 책임 수행한다. 다른 객체는 이 객체가 어떤 방식으로 책임을 수행하는지 알 필요가 없다.

 

책임: 요청을 처리하기 위해 객체가 수행하는 행동

적절한 책임?

자율적인 객체끼리의 유연하고 단순한 협력이 가능해진다.

 

상세한 수준의 책임?

선택의 자유를 침해하고 유연하지 못한 설계가 될 수 있다.

결론적으로, 협력에 참여하는 의도를 명확하게 설명할 수 있는 수준 내에서 추상적이어야 한다. 

 

결론: "적절한, 적당한 책임"이 중요하다.

 예를들어, 커피를 머신으로 만든다, 드립으로 만든다. 등의 상세한 책임 대신 "커피를 만든다"라는 적당히 추상적인 책임을 줄 수 있다.

 

 

- 자율적인 책임은 어떻게가 아닌 무엇을 설명해야 한다. ->  머신으로, 드립으로를 빼고 "커피를" 만든다를 설명.

 

 

 

메시지와 메서드

 

메시지

객체가 다른 객체에 접근할 수 있는 유일한 방법

모자장수.증언하라(어제, 왕국) => 메시지

 

 

메서드

메시지를 처리하기 위해 내부적으로 선택하는 방법

 

 

다형성

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

서로 다른 객체들이 다형성을 만족시킨다는 것?

- 객체들이 동일한 책임을 공유한다는 것. 그리고 그 책임을 다른 방식으로 수행한다는 것.

- "송신자"의 관점에서 바라봐야 한다.

- 송신자는 다형적인 수신자들을 구별할 필요가 없으며 자신의 요청을 수행할 책임을 지닌다는 점에서 모두 동일하다.

- 즉, 수신자는 송신자의 관점에서 캡슐화된다.

- 다형성은 동일한 역할을 수행할 수 있는(=동일한 메시지를 수신할 수 있는) 객체들 사이의 대체 가능성을 의미한다. 그 역할을 수행할 수 있다면 다른 객체가 대체해도 관계 없다.

- 이것은 설계를 유연하고 재사용 가능하게한다.

- 이를 통해 송신자에 영향을 주지 않고도 수신자의 타입을 추가할 수 있다.

- 다형성을 이용하면 메시지를 이해할 수 있는 어떤 객체와도 협력할 수 있는 유연하고 확장 가능한 구조를 만들 수 있다.

 

 

송신자가 수신자에 대해 매우 적은 정보만 알고도 상호협력이 가능하다는 사실은?

- 협력을 유연하게 한다. = 수신자가 메시지를 이해하기만 하면 된다.

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

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

 

 

메시지를 따라라

- 객체지향 애플리케이션의 중심 사상은 연쇄적으로 메시지를 전송하고 수신하는 객체들 사이의 협력 관계를 기반으로 사용자에게 유용한 기능을 제공하는 것이다.

- 클래스를 정의하는 것이 먼저가 아니라 객체들의 속성과 행위를 식별하는 것이 먼저이다.

- 클래스를 정의하려 하지 말고 메시지를 주고받는 동적인 객체들의 집합으로 바라보자.

- 객체의 내부는 감춰져야 한다. -> 독립된 객체의 데이터를 기반으로 설계하면 객체의 내부에 집중하게 된다.

- 객체는 협력이라는 문맥 안에서 설계되어야 한다. 즉, 다른 객체에게 제공해야 하는 메시지를 찾자.

- 객체가 어떤 메시지를 전송할 수 있고 어떤 메시지를 이해할 수 있는지에 대해 집중하자.

- 결과적으로 "메시지"가 "객체"를 선택해야 한다.

 

 

책임-주도 설계

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

 

What/Who 사이클

협력 관계 설계 시 어떤 행위(메시지)를 수행할 것인지를 결정한 후, 누가 그 행위를 수행할 것인지를 결정해야 한다.
= 협력이라는 문맥 안에서 필요한 메시지를 먼저 결정한 후에 메시지를 수신하기에 적합한 객체를 선택하고, 수신된 메시지가 객체의 책임을 결정한다.

 

 

묻지말고 시켜라

메시지 송신자는 수신자의 내부를 알 수 없다.

= 수신자의 캡슐화는 올리고

= 수신자와 송신자의 결합도는 낮추고

= 자율적인 객체로

 

 

메시지에 초점을 맞춤으로써 재사용, 확장 가능한 다형성의 진가를 발견할 수 있다

 

 

 

객체 인터페이스

 

- 내부 구조를 몰라도 대상을 조작할 수 있도록 함

- 인터페이스만 변경되지 않으면 내부 구조를 바꿔도 동작에 문제 없음

- 대상이 변경되어도 동일 인터페이스를 사용한다면 문제 없음

 

공용 인터페이스?

외부에 공개된 인터페이스 -> 외부에서 수신할 수 있는 메시지 목록

 

인터페이스와 구현의 분리

: 좀 더 추상적인 인터페이스

: 수신자의 자율성을 보장한다.

 

최소 인터페이스

노출을 최소화 한다.

= 수정하더라도 외부에 미치는 영향을 최소화한다.

 

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

: 객체의 상태와 메서드는 구현이다.

 

 

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

- 변경에 대한 영향 최소화

- 송신자와 수신자가 느슨한 인터페이스에 관해서만 결합되도록

- 캡슐화

  > 상태와 행위의 캡슐화 = 데이터 캡슐화 => "자율적인 객체"

  > 사적인 비밀의 캡슐화: 사적인 부분을 외부의 간섭 없이 변경

 

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

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

- 세부적인 사항들은 무시하고 의도를 나타내는 하나의 문장으로 표현함으로써 협력을 단순하게 만든다.

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

  > 요청하는 객체가 몰라도 되는 사적인 부분이 객체 내부로 캡슐화되기 때문에 인터페이스와 구현이 분리된다.

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

  > 책임이 자율적일수록 변경에 의해 수정돼야 하는 범위가 좁아지고 명확해진다. 변경에 대한 파급 효과가 객체 내부로 캡슐화 되기 떄문에 두 객체간 결합도가 낮아진다.

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

  > 설계가 유연해지고 재사용성이 높아진다.

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

  > 책임이 자율적일수록 객체의 응집도를 높은 상태로 유지하기 쉬워진다.(강하게 연관된 책임들)