[오브젝트 : 코드로 이해하는 객체지향 설계] 5. 책임 할당하기

1. 책임 주도 설계

• 데이터보다 행동을 먼저 결정하라
• 협력이라는 문맥 안에서 책임을 결정하라

책임 주도 설계의 흐름

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

2. GRASP패턴

GRASP(General Responsibility Assignment Software Pattern)⇒ 일반적인 책임 할당을 위한 소프트웨어 패턴으로 객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합

영화 예매 시스템을 구성하는 도메인 개념

정보 전문가에게 책임을 할당하라

• 메시지를 전송할 객체는 무엇을 원하는가?
• 메시지를 수신할 적합한 객체는 누구인가?

정보 전문가 패턴(INFORMATION EXPERT) ⇒ 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것

높은 응집도와 낮은 결합도

낮은 결합도(LOW COUPLING)패턴과 높은 응집도(HIGH COHESION)패턴

• 낮은 결합도 ⇒ 도메인 상으로 이미 영화와 할인 정책은 결합되어 있다.
• 높은 응집도 ⇒ 상영의 가장 중요한 책임은 예매를 생성하는 것이다.

창조자에게 객체 생성 책임을 할당하라

영화 예매 협력의 최종 결과물은 Reservation인스턴스를 생성하는 것이다.

⇒ 협력에 참여하는 어떤 객체에게는 Reservation인스턴스를 생성할 책임을 할당해야 한다는 것

창조자(CREATOR) 패턴 ⇒ 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공

변경의 이유를 파악하는 방법

1. 인스턴스 변수가 초기화되는 시점을 살펴본다. ⇒ 클래스의 속성이 서로 다른 시점에 초기화되거나 일부만 초기화된다는 것은 응집도가 낮다는 증거이다.
2. 메서드들이 인스턴스 변수를 사용하는 방식을 살펴본다. ⇒ 메서드들이 사용하는 속성에 따라 그룹이 나뉜다면 클래스의 응집도가 낮다고 볼 수 있다.

※ 응집도를 높이기 위해서는 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다.

다형성(POLTMORPHISM) 패턴 ⇒ 객체의 타입에 따라 변하는 행동이 있으면 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하는 것

변경 보호(PROTECTED VARIATIONS) 패턴 ⇒ 변경을 캡슐화하도록 책임을 할당하는 것

변경과 유연성

변경에 대비할 수 있는 두 가지 방법

1. 코드를 이애하고 수정하기 쉽도록 단순하게 설계한다.
2. 코드를 수정하지 않고 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것