오브젝트 - 책임 할당하기

이 객체가 수행해야 하는 책임은 무엇인가 를 결정한 후에 이 책임을 수행하는데 필요한 데이터는 무엇인가를 결정한다

GRASP (General Responsibility Assignment Software Pattern)

책임을 할당받을 객체들의 종류와 관계에 대한 유용한 정보를 제공할 수 있으면 충분하다

메시지를 전송할 객체는 무엇을 원하는가? ex. 예매하라
메시지를 수신할 적합한 객체는 누구인가? 객체가 상태와 행동을 통합한 캡슐화의 단위. 객체는 자신의 상태를 스스로 처리하는 자율적인 존재. 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당한다 ex. 상영(Screening) 메시지를 수신했을 때 수행해야 하는 작업의 흐름을 생각해보자

예매하라 -> Screening -> 가격을 계산하라 -> Movie -> 할인 여부를 판단하라 -> DiscountCondition

결합도
- Screening은 DiscountCondition과 새로운 결합도를 생성한다 따라서 Movie와 DiscountCondition 협력이 더 나은 대안
응집도
- 예매 요금을 계산하는 방식이 변경될 경우 Screening 변경. 할인 여부 계산하는 방법이 달라질시 Screening 변경 필요
- Movie의 경우 영화 요금을 계산하는 것. 할인 조건을 판단하기 위해 협력하는 것은 응집도에 아무런 해도 끼치지 않음

어떤 객체에게 객체 생성 책임을 할당해야 하는지. 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것

함께 초기화되는 속성을 기준으로 코드를 분리
모든 메서드가 객체의 모든 속성을 사용한다면 클래스의 응집도는 높다고 본다 => 속성 그릅과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리

역할을 사용하면 객체의 구체적인 타입을 추상화할 수 있다.
역할을 대체할 클래스들 사이에서 구현을 공유해야 할 필요가 있다면 추상 클래스. 구현을 공유할 필요 없이 역할을 대체하는 객체들의 책임만 정의하고 싶다면 인터페이스 사용
DiscountCondition의 경우. 객체의 암시적인 타입에 따라 행동을 분기해야 한다면 암시적인 타입을 명시적인 클래스로 정의하고 행동을 나눔으로써 응집도 문제를 해결할 수 있다

새로운 할인 정책이 추가될 때마다 인스턴스를 생성하고 상태를 복사하고 식별자를 관리하는 코드를 추가하는 일은 번거로울뿐만 아니라 오류 발생한다 => 상속대신 합성을 사용한다.

yepdi / TIL