[오브젝트] 03. 역할, 책임, 협력

책에서 기억하고 싶은 내용

협력

협력은 두 개 이상 객체가 메세지 전송을 통한 커뮤니케이션을 나누며, 수신한 메세지는 각 객체의 메서드를 실행해 요청에 응답한다.
이런 객체를 자율적으로 만드는 가장 기본적인 방법은 내부 구현을 “캡슐화” 하는 것이다. 이를 통해 변경에 대한 파급효과(사이드이펙트)를 제한할 수 있다.
객체는 자신의 상태를 스스로 결정하고 관리하는 자율적인 존재, 따라서 객체가 수행하는 행동에 필요한 상태도 함께 가지고 있어야함.

 

책임

객체가 “무엇을 알고 있는가’와 ‘무엇을 할 수 있는 가’로 구성된다.

 

하는 것

• 객체 생성, 계산 등 스스로 행하는 것
• 다른 객체의 행동을 시작
• 다른 객체의 활동 제어 조절

아는 것

• 사적인 정보(자기 상태?)
• 관련된 객체
• 자신이 유도하거나 계산할 수 있는 것에 대해

책임은 객체가 수행할 수 있는 행동을 종합적이고 간략하게 서술하기 때문에 메세지보다 추상적이고 개념적으로도 더 큼.
객체가 책임을 수행하게 하는 유일한 방법은 메세지를 전송하는 것, 책임을 할당한다는 것은 메세지의 이름을 결정하는 것과 같음.

1. 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.
2. 시스템 책임을 더 작은 책임으로 분할한다.
3. 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당.
4. 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.
5. 해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

 

메세지가 객체를 결정하고, 행동이 상태를 결정한다.

객체의 행동이 객체가 협력에 참여할 수 있는 유일한 방법이다.

객체의 행동이 아니라 상태에 초점을 맞추는 것은 쉽게 빠지는 실수다.

이런 방식은, 캡슐화를 저해하고 내부 구현을 변경하면 영향이 전파되는 문제가 발생한다.

 

협력이라는 문맥 안에서 객체를 생각하도록 하자.
협력에 초점을 맞춰야 응집도가 높고 결합도가 낮은 객체들을 창조 할 수 있다.
행동이 중요하다.

 

특정한 목적 = 협력, 협력 안에서 책임 = 역할 즉, 협력 ⇒ 책임을 가진 역할이다.

역할은 유현하고 재사용 가능한 협력을 만들 수 있다.
협력을 해주는 객체를 개별적으로 만들기 전에, 어떤 책임을 져야하는지 초점을 맞추자.

만약, 개별적으로 만들면 중복된 코드가 많이 생길 것이다. 중복된 코드는 모든 문제의 근원이 될 수 있다.

역할을 구현하는 일반적인 방법은, 추상 클래스와 인터페이스를 사용하는 것이다.
역할은 객체가 참여할 수 있는 일종의 슬롯.
좀더 친근한 표현으로 배역이라 할 수 있다. 반대로 객체는 배우다.
배우가 여러 연극에 참여하면서 여러 배역을 연기하는 것 처럼, 객체 역시 여러 협력에 참여하면서 다양한 역할을 수행할 수 있다.
협력 → 역할 → 객체 → 클래스

 

떠오르는 생각

클래스를 처음 배울때, 붕어빵틀에 비유하던 비유가 생각났다.
연극의 배역에 비유하여 역할을 이야기하는 것은 좋은 비유인 거 같다.
소프트웨어는 하나의 드라마며, 그안에 다양한 배역들이 이야기를 이뤄나가는 것처럼, 역할이 있는 객체들을 만들어 유연하게 작동하는 것이라고 생각하면 좀더 이 장의 이야기가 쉬운 것 같은 느낌이 든다.