※ 이글은 독자를 전혀 배려하지 않고 그냥 제가 정리하고 싶은 내용 정리하는 글입니다.
129p~159p
5. 책임 할당하기
책임 중심 설계를 위해
- 데이터보다는 행동을 먼저 결정하라
- 협력이라는 문맥 안에서 책임을 결정하라
객체가 메시지를 선택하는 것이 아닌, 메시지가 객체를 선택해야 한다.
객체를 만들었기에 메시지가 필요한 것이 아닌, 메시지를 전송하기 떄문에 객체를 갖게된 것이다.
-> 이러한 방식으로 협력을 설계하면 기본적으로 메시지 수신자가 깔끔하게 캡슐화된다.
책임 할당을 위한 GRASP 패턴
- General Responsibility Assignment Software Pattern
1.도메인 개념에서 출발하기
- 도메인 개념들을 책임 할당의 대상으로 사용하면 코드에 도메인의 모습을 투영하기가 좀 더 수월해진다.
- 설계를 시작하는 단계에서 개념들의 의미와 관계가 정확하거나 완벽할 필요는 없다. 단지 우리에게는 출발점이 필요할 뿐이다.
2.정보 전문가에게 책임을 할당하라
- 책임 주도 설계의 첫 단계는 애플리케이션이 제공할 기능을 애플리케이션의 책임으로 생각하는 것이다. 이 메시지를 책임질 첫 객체를 선택해야 한다.
- 정보 전문가: 책임을 수행할 정보를 알고있는 객체. 여기서 정보는 항상 객체에 데이터로써 저장될 필요는 없음
- 객체가 스스로 처리할 수 없는 작업이라면, 외부에 도움을 요청해라.
3. 높은 응집도와 낮은 결합도
- 책임을 할당할 수 있는 다양한 대안들이 있다면, 응집도와 결합도 측면에서 더 나은 대안을 선택하는 것이 좋다.
4. 참조자에게 객체 생성 책임을 할당하라
- 창조자는 생성할 객체의 정보 전문가면서, 낮은 결합도를 유지할 수 있게 선택하라. (그냥 이전까지 나온 내용을 조합하면 쉽게 이해가 가능)
- 올바른 설계를 하고 있는지 확인하기 위해서는 코드를 작성하라.
구현을 통한 검증
- 낮은 응집도가 초래하는 문제를 해결하기 위해서는 변경의 이유에 따라 클래스를 분리해야 한다.
- 구현 후, 설계를 개선하는 작업은 변경의 이유가 하나 이상인 클래스를 찾는 것으로부터 시작하는 것이 좋다.
코드를 통해 변경의 이유 파악하기
1. 인스턴스 변수가 초기화되는 시점 살펴보기. 응집도가 높은 클래스는 인스턴스 생성시 모든 속성을 함께 초기화한다. 함께 초기화되는 속성을 기준으로 코드를 분리하라
2. 메서드들이 인스턴스 변수를 사용하는 방식, 메서드들이 사용하는 속성이 특정 그룹에 따라 나뉘는 것처럼 보인다면 클래스의 응집도가 낮다고 볼 수 있다.
다형성 패턴: 객체의 타입에 따라 변하는 패턴이 있다면 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하라.
변경 보호 패턴: 역할 등을 통해 변경을 캡슐화하도록 책임을 할당하는 것. 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라.
응집도를 낮추기 위한 방법을 정리하자면
1. 변경의 이유가 하나 이상인 클래스를 분리하라
2. 인스턴스 변수의 초기화 타이밍을 기준으로 클래스를 분리하라
3. 몇개의 클래스의 메서드들이 특정 인스턴스 변수만을 사용한다면 그 변수를 기준으로 클래스를 분리하라
