- 책임에 초점을 두자
- 어떤 객체에게 어떤 책임을 할당할 것인가
- GRASP 패턴
01 책임 주도 설계를 향해
데이터보다 행동을 먼저 결정하라
- 데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공
- 행동을 결정한 후에 데이터를 결정해야 한다 .
협력이라는 문맥 안에서 책임을 결정하라
- 협력에 적합한 책임 = 메시지 전송자에게 적합한 책임
- 메시지가 객체를 선택하게 해야 한다.
- "메시지를 전송해야 하는데 누구에게 전송해야 하지?"
- 메시지지를 수신하기로 결정된 객체는 메시지를 처리할 '책임'을 할당받게 된다.
- 책임을 할당하기 위해서는 협력이라는 문맥을 고려해야 한다.
책임 주도 설계
- 시스템의 책임을 파악 → 책임을 더 작음 책임으로 분할 → 적절한 객체에게 역할을 찾아 책임을 할당 → 책임을 수행하는데 도움이 필요하다면 이를 책임질 적절한 객체 또한 역할을 찾아 책임을 할당
- 위와 같은 과정을 통해 객체 협력을 형성하게 된다.
02 책임 할당하기 위한 GRASP 패턴
- GRASP(General Responsibility Assignment Software Pattern)
- 일반적인 책임 할당을 위한 소프트웨어 패턴
도메인 개념에서 출발하기
- 설계를 시작하기 전에 도메인에 대한 개략적인 모습을 그려 보는 것이 유용
- 객체들의 종류와 관계에 대한 유용한 정보를 제공할 수 있다면 충분
정보 전문가에게 책임을 할당하라
- 메시지를 책임질 첫 번째 객체를 선택하는 것으로 설계를 시작한다.
- (1) 메시지를 전송할 객체는 무엇을 원하는가
- (2) 메시지를 수신할 적합한 객체는 누구인가
- 정보를 알고 있는 객체에게 책임을 할당하라
- INFROmATION EXPERT(정보 전문가) 패턴
- 여기서 정보는 데이터를 의미하는 것이 아니다.
- "정보를 알고 있다"와 "정보를 저장 하고 있다"는 다르다.
- "정보를 알고 있다"
- 정보를 제공할 수 있는 다른 객체를 알고 있거나 필요한 정보를 계산해서 제공할 수 있다.
- 스스로 처리할 수 없는 작업이 있다면 외부에 도움을 요청하자
- 해당 요청이 새로운 메시지가 된다.
- 이러한 메시지 전송과 수신을 통해 협력 공동체가 구성되는 것이다.
높은 응집도와 낮은 결합도
- 항상 응집도는 높이고 결합도는 낮힐 수 있는 방향으로 책임을 할당하라
창조자에게 객체 생성 책임을 할당하라
- CREATOR(창조자) 패턴
- 아래 조건을 최대한 만족하는 B에게 객체 생성을 할당하라
- B가 A객체를 포함하거나 참조한다.
- B가 A객체를 기록한다.
- B가 A객체를 긴밀하게 사용한다.
- B가 A객체를 초기화하는 데 필요한 데이터를 가지고 있다.
- 객체와 연결되거나 관련될 필요가 있는 객체엑 해당 객체를 생성할 책임을 맡기는 것이다.
- 아래 조건을 최대한 만족하는 B에게 객체 생성을 할당하라
03 구현을 통한 검증
DiscountCondition 개선하기
- 변경의 이유에 따라 클래스를 분리해라
- 다른 이유로, 서로 다른 시점에 변경될 확률이 높다 → 응집도가 낮아진다.
- 클래스 분리 for 높은 응집도
- 함께 초기화 되는 속성을 기준으로 코드를 분리(초기화 시점에 따른 코드 분리)
- 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 분리
- 응집도가 낮은 경우
- 하나 이상의 이유로 변경되어야 하는 경우
- 인스턴스를 초기화하는 시점에 따라 서로 다른 속성을 초기화하고 있는 경우
- 메서드 그룹이 속성 그룹을 사용하는지 여부로 나뉘는 경우
타입 분리하기
다형성을 통해 분리하기
- 역할
- 협력 안에서 대체 가능성을 의미
- POLYMORPHISM(다형성) 패턴
- 타입에 따라 변하는 행동이 있다면 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하는 것
변경으로부터 보호하기
- PROTECTED VARIATION(변경 보호) 패턴
- 변경을 캡슐화 하여 다른 객체에 영향을 받지 않도록 한다.
Movie 클래스 개선하기
변경과 유연성
- 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것
- 상속 대신 합성을 이용하라
04 책임 주도 설계의 대안
메서드 응집도
- 긴 메서드(몬스터 메서드)
- 코드를 전체적으로 이해하는데 너무 많은 시간이 소모
- 변경이 필요할 때 수정해야할 부분을 찾기가 어려움
- 재사용하는 것이 불가능
- 코드 중복 초래하기 쉬움
- 쉽게 말해 응집도가 낮다
- 응집도가 높다
- 변경되는 이유가 단 하나여야 한다.
- 응집도를 높이기 위해서는 변경의 이유가 다른 메서드들을 적절한 위치로 분배해야 한다.
객체를 자율적으로 만들자
소유하고 있는 데이터를 자기 스스로 처리하도록 만들자.
꾸준히 나아가자 🐢