[오브젝트] 5장. 책임 할당하기

책임 할당

- 데이터 중심 설계로 인해 발생하는 문제점을 해결할 수 있는 가장 기본적인 방법은 데이터가 아닌 책임에 초점을 맞추는 것이다.

- 책임 할당 과정은 일종의 트레이드오프 활동이다. 동일한 문제를 해결할 수 있는 다양한 책임 할당 방법이 존재하며, 어떤 방법이 최선인지는 상황과 문맥에 따라 달라진다.

- 데이터 중심 설계에서 책임 중심 설계로 전환할 때 따라야 하는 두 가지 원칙

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

- 협력에 적합한 책임을 수확하기 위해서는 객체를 결정한 후에 메시지를 선택하는 것이 아니라 메시지를 결정한 후에 객체를 선택해야 한다. 메시지가 존재하기 때문에 그 메시지를 처리할 객체가 필요한 것이다. 객체가 메시지를 선택하는 것이 아니라 메시지가 객체를 선택하게 해야 한다.

 

---

GRASP 패턴

: General Responsibility Assignment Software Pattern. 객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합을 패턴 형식으로 정리한 것.

 

1. Information Expert (정보 전문가) 패턴

• 책임을 수행하는 데 필요한 정보를 가지고 있는 객체에게 할당하라.
• 필요한 정보를 가진 객체들로 책임이 분산되므로 더 응집력있고, 이해하기 쉬워진다.
• 결과적으로 결합도가 낮아져서 간결하고 유지보수 하기 쉬운 시스템을 구축할 수 있다.

 

2. Low Coupling (낮은 결합도) 패턴

• 어떻게 하면 의존성을 낮추고 변화의 영향을 줄이며 재사용성을 증가시킬 수 있을까?
• 설계의 전체적인 결합도가 낮게 유지되도록 책임을 할당하라.

 

3. High Cohesion (높은 응집도) 패턴

• 어떻게 복잡성을 관리할 수 있는 수준으로 유지할 것인가?
• 높은 응집도를 유지할 수 있게 책임을 할당하라.

 

4. Creator 패턴

• 객체 A를 생성해야 할 때 어떤 객체에게 객체 생성 책임을 할당해야 하는가?
• 아래 조건을 최대한 많이 만족하는 B에게 객체 생성 책임을 할당하라.

• B가 A 객체를 포함하거나 참조한다.
• B가 A 객체를 기록한다.
• B가 A 객체를 긴밀하게 사용한다.
• B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다. (이 경우 B는 A에 대한 정보전문가이다.)

Creator 패턴의 의도는 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것이다. 결과적으로 Creator 패턴은 이미 존재하는 객체 사이의 관계를 이용하기 때문에 설계가 낮은 결합도를 유지할 수 있게 한다.

 

5. Polymorphism (다형성) 패턴

• 객체의 타입에 따라 변하는 로직이 있을 때 이 로직을 담당할 책임을 어떻게 할당해야 하는가?
• 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당하라.

Polymorphism 패턴은 객체의 타입을 검사해서 타입에 따라 여러 대안들을 수행하는 조건적인 논리를 사용하지 말라고 경고한다. 대신 다형성을 이용해 새로운 변화를 다루기 쉽게 확장하라고 권고한다.

 

6. Protected Variations (변경 보호) 패턴

• 객체, 서브시스템, 그리고 시스템을 어떻게 설계해야 변화와 불안정성이 다른 요소에 나쁜 영향을 미치지 않도록 방지할 수 있을까?
• 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라.
• 변경이 될 가능성이 높은가? 그렇다면 캡슐화 하라.

 

---

코드 변경

- 개발자로서 변경에 대비할 수 있는 두 가지 방법이 있다. 하나는 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계하는 것. 다른 하나는 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것이다.

- 리팩터링(Refactoring) : 이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해 겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것.

- 긴 메서드는 다양한 측면에서 코드의 유지보수에 부정적인 영향을 미친다.

1. 어떤 일을 수행하는지 한눈에 파악하기 어렵기 때문에 코드를 전체적으로 이해하는데 너무 많은 시간이 걸린다.
2. 하나의 메서드 안에서 너무 많은 작업을 처리하기 때문에 변경이 필요할 때 수정해야 할 부분을 찾기 어렵다.
3. 메서드 내부의 일부 로직만 수정하더라도 메서드의 나머지 부분에서 버그가 발생할 확률이 높다.
4. 로직의 일부만 재사용하는 것이 불가능하다.
5. 코드를 재사용하는 유일한 방법은 원하는 코드를 복사해서 붙여 넣는 것뿐이므로 코드 중복을 초래하기 쉽다.