P.86 ~ P.115 요약
3. 역할, 책임, 협력
03 역할
역할과 협력
- 객체가 어떤 특정한 협력 안에서 수행하는 책임의 집합을 역할이라고 부른다
- 실제로 협력을 모델링할 때는 특정한 객체가 아니라 역할에게 책임을 할당한다고 생각하는게 좋다
- 역할은 다른 것으로 교체할 수 있는 책임의 집합이다
역할의 구현
- 역할을 구현하는 가장 일반적인 방법은 추상 클래스와 인터페이스를 사용하는 것이다
- 일단 협력 안에서 역할이 어떤 책임을 수행해야 하는지를 결정하는 것이 중요하다
- 역할은 객체를 추상화해서 객체 자체가 아닌 협력에 초점을 맞출 수 있게 한다
객체 대 역할
- 배우가 극중에서 믿을 수 있는 배역을 맡아서 하려는 것처럼 객체는 의미 있는 역할을 정의하는 책임을 통해 애플리케이션의 기능을 담당하게 된다
- 협력은 역할들의 상호작용으로 구성되고, 협력을 구성하기 위해 역할에 적합한 객체가 선택되며, 객체는 클래스를 이용해 구현되고 생성된다
- 설계 초반에는 적절한 책임과 협력의 큰 그림을 탐색하는 것이 가장 중요한 목포여야 한다
- 동일한 책임을 서로 다른 방식으로 수행할 수 있는 객체들이 필요해질 때가 왔을 때 역할의 도입을 고려해도 늦지 않다
역할과 추상화
- 상위 수준에서 협력을 설명하면 구체적인 객체들이 가지는 복잡성을 제거하고 단순화해서 표현할 수 있다
- 역할을 사용하면 간단히 '할인 정책과 여러 개의 할인 조건을 적용한다'로 줄여서 표현하면 된다
- 역할은 모양이나 구조에 의해 정의될 수 없으며 오직 시스템의 문맥 안에서 무엇을 하는지에 의해서만 정의될 수 있다
4. 설계 품질과 트레이드오프
개요
- 책임은 객체의 상태에서 행동으로, 나아가 객체와 객체 사이의 상호작용으로 설계 중심을 이동시키고, 결합도가 낮고 응집도가 높으며 구현을 효과적으로 캡슐화하는 객체들을 창조할 수 있는 기반을 제공한다
- 상태를 객체 분할의 중심축으로 삼으면 구현에 관한 세부사항이 객체의 인터페이스에 스며들게 되어 캡슐화의 원칙이 무너진다
- 객체는 책임을 드러내는 안정적인 인터페이스 뒤로 책임을 수행하는 데 필요한 상태를 캡슐화함으로써 구현 변경에 대한 파장이 외부로 퍼져나가는 것을 방지한다
02 설계 트레이드오프
캡슐화
- 객체를 설계하기 위한 가장 기본적인 아이디어는 변경의 정도에 따라 구현과 인터페이스를 분리하고 외부에서는 인터페이스에만 의존하도록 관계를 조절하는 것이다
응집도화 결합도
- 하나의 변경을 수용하기 위해 모듈 전체가 함께 변경된다면 응집도가 높은 것이고 모듈의 일부만 변경된다면 응집도가 낮은 것이다
- 응집도가 높은 설계에서는 하나의 요구사항 변경을 반영하기 위해 오직 하나의 모듈만 수정하면 된다
- 낮은 결합도를 가진 설계에서는 모듈 A를 변경했을 때 오직 하나의 모듈만 영향을 받는다
