🌈 Chapter 5: 책임 할당하기

📚 책임 주도 설계를 향해

• 데이터 중심의 설계에서 책임 중심의 설계로 전환하기 위해서는 다음의 두 가지 원칙을 따라야 한다.
  • 데이터보다 행동을 먼저 결정한다.
  • 협력이라는 문맥 안에서 책임을 결정하라.

🎈 데이터보다 행동을 먼저 결정하라

• 객체에게 중요한 것은 데이터가 아니라 외부에 제공하는 행동이다.
• 클라이언트의 관점에서 객체가 수행하는 행동이란 곧 객체의 책임을 의미한다. 데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공할 뿐이다.
• 책임 중심의 설계에서는 이 객체가 수행해야 하는 책임은 무엇인가를 결정한 후에 이 책임을 수행하는 데 필요한 데이터는 무엇인가를 결정한다. 다시 말해 객체의 행동, 즉 책임을 먼저 결정한 후에 객체의 상태를 결정한다는 것이다.

🎈 협력이라는 문맥 안에서 책임을 결정하라

• 객체에 입장에서는 책임이 조금 어색해 보이더라도 협력에 적합하다면 그 책임은 좋은 것이다. 책임은 객체의 입장이 아니라 객체가 참여하는 협력에 적합해야 한다.
• 메시지를 전송하는 클라이언트의 의도에 적합한 책임을 할당해야 한다. (메시지 전송자에게 적합한 책임)
• 협력에 적합한 책임을 수확하기 위해서는 객체를 결정한 후에 메시지를 선택하는 것이 아니라 메시지를 결정한 후에 객체를 선택해야 한다.
• 메시지를 먼저 결정하기 때문에 메시지 송신자는 메시지 수신자에 대한 어떠한 가정도 할 수 없다. 때문에 멤시지 전송자의 관점에서 메시지 수신자가 깔끔하게 캡슐화되는 것이다.

📚 책임 할당을 위한 GRASP 패턴

• 책임 할당 기법중 가장 널리 알려진 크레이크 라만의 패턴 형식인 GRASP 패턴(일반적인 책임 할당을 위한 소프트웨어 패턴)이다.

🎈 도메인 개념에서 출발하기

• 어떤 책임을 할당해야 할 때 가장 먼저 고민해야 하는 도메인 개념이다.
• 도메인은 설계를 시작하기 위해 참고할 수 있는 개념들의 모음 정도로 간주하고, 중요한 것은 설계를 시작하는 것이지 도메인 개념들을 완벽하게 정리하는 것이 아니다.
• 도메인 개념을 정리하는 데 너무 많은 시간을 들이지 말고 빠르게 설계와 구현을 진행하라.

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

• 책임 주도 설계의 첫 단계는 애플리케이션이 제공해야 하는 기능을 애플리케이션의 책임으로 생각하는 것이다. 이 책임을 애플리케이션에 대해 전송된 메시지로 간주하고 이 메시지를 책임질 첫 번째 객체를 선택하는 것으로 설계를 시작한다.

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

• 두 번째 질문에 답하기 위해서는 객체가 상태와 행동을 통합한 캡슐화의 단위라는 사실에 집중해야 한다. 객체의 책임과 상태는 동일한 객체 안에 존재해야 한다. 따라서 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하는 것이다.
• GRASP에서는 이를 INFORMATION EXPERT(정보 전문가) 패턴이라고 부른다. (책임을 수행하는 데 필요한 정보를 가지고 있는 객체에게 할당하라.)
• 만약 스스로 처리할 수 없는 작업이 있다면 외부에 도움을 요청하고 이 요청이 외부로 전송해야 하는 새로운 메시지가 되고, 최종적으로 이 메시지가 새로운 객체의 책임으로 할당된다. 이 같은 연쇄적인 메시지 전송과 수신을 통해 협력 공동체가 구성되는 것이다.
• INFORMATION EXPERT 패턴은 객체란 상태와 행동을 함께 가지는 단위라는 객체지향의 가장 기본적인 원리를 책임 할당의 관점에서 표현한다.

🎈 높은 응집도와 낮은 결합도

• 책임을 할당할 수 있는 다양한 대안들이 존재한다면 응집도와 결합도의 측면에서 더 나은 대안을 선택하는 것이 좋다. 다시 말해 두 협력 패턴 중에서 높은 응집도와 낮은 결합도를 얻을 수 있는 설계가 있다면 그 설계를 선택해야 한다는 것이다.
• GRASP에서는 이를 LOW COUPLING(낮은 결합도) 패턴과 HIGH COHESION(높은 응집도) 패턴이라고 부른다.
• LOW COUPLING 패턴은 어떻게 하면 의존선을 낮추고 변화의 영향을 줄이며 재사용성을 증가시킬 수 있을까를 고민하고 설계의 전체적인 결합도가 낮게 유지되도록 책임을 할당하는 것이다.
• HIGH COHESION 패턴은 어떻게 하면 복잡성을 관리할 수 있는 수준으로 유지할 것인가를 고민하고 높은 응집도를 유지할 수 있게 책임을 할당하는 것이다.

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

• GRASP의 CREATOR(창조자) 패턴은 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공한다.
• CREATOR 패턴은 객체 A를 생성해야 할 때 어떤 객체에게 객체 생성 책임을 할당해야 하는지를 고민하고 아래 조건을 최대한 많이 만족하는 B에게 객체 생성 책임을 할당하는 것이다.
  • B가 A 객체를 포함하거나 참조한다.
  • B가 A 객체를 기록한다.
  • B가 A 객체를 긴밀하게 사용한다.
  • B가 A 객체를 초기화하는 데 필요한 데이터를 가지고 있다. (B는 A에 대한 정보 전문가다.)
• CREATOR 패턴의 의도는 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것이다.

📚 구현을 통한 검증

📌 대부분은 2장의 영화예매 예제와 비슷하기 때문에 많은 내용은 생략합니다. (P146 ~ P165)

• 낮은 응집도가 초래하는 문제를 해결하기 위해서는 변경의 이유에 따라 클래스를 분리해야 한다. 설계를 개선하는 작업은 변경의 이유가 하나 이상인 클래스를 찾는 것으로부터 시작하는 것이 좋다.
• 코드를 통해 변경의 이유를 파악할 수 있는 첫 번째 방법은 인스턴스 변수가 초기화되는 시점을 살펴보는 것이다. 응집도가 낮은 클래스는 객체의 속성 중 일부만 초기화하고 일부는 초기화되지 않은 상태로 남겨진다. 따라서 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다.
• 코드를 통해 변경의 이유를 파악할 수 있는 두 번째 방법은 메서드들이 인스턴스 변수를 사용하는 방식을 살펴보는 것이다. 메서드들이 사용하는 속성에 따라 그룹이 나뉜다면 클래스의 응집도가 낫다고 볼 수 있다. 이 경우 응집도를 높이기 위해서는 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다.

🎈 다형성을 통해 분리하기

• 역할을 사용하면 객체의 구체적인 타입을 추상화할 수 있는데, 역할을 대체할 클래스들 사이에서 구현을 공유해야 할 필요가 있다면 추상 클래스를 사용하면 된다. 구현을 공유할 필요 없이 역할을 대체하는 객체들의 책임만 정의하고 싶다면 인터페이스를 사용하면 된다.
• 객체의 암시적인 타입에 따라 행동을 분기해야 한다면 암시적인 타입을 명시적인 클래스로 정의하고 행동을 나눔으로써 응집도 문제를 해결할 수 있다. 다시 말해 객체의 타입에 따라 변하는 행동이 있다면 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하라는 것이다. GRASP에서는 이를 POLYMORPHISM(다형성) 패턴이라고 부른다.
• POLYMORPHISM 패턴은 객체의 타입에 따라 변하는 로직이 있을 때 변하는 로직을 담당할 책임을 어떻게 할당해야 하는가를 고민하고 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당해야 한다.

🎈 변경으로부터 보호하기

• 변경을 캡슐화하도록 책임을 할당하는 것을 GRASP에서는 PROTECTED VARIATIONS(변경 보호) 패턴이라고 부른다.
• 객체, 서브시스템, 그리고 시스템을 어떻게 설계해야 변화와 불안정성이 다른 요소에 나쁜 영향을 미치지 않도록 방지할 수 있을지를 고민하고 변화가 예상되는 불안정한 지점들을 식별하고 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당하라.
• 클래스를 변경에 따라 분리하고 인터페이스를 이용해 변경에 캡슐화하는 것은 설계의 결합도와 응집도를 향상시키는 매우 강력한 방법이다.
• 하나의 클래스가 여러 타입의 행동을 구현하고 있는 것처럼 보인다면 클래스를 분해하고 POLYMORPHISM 패턴에 따라 책임을 분산시킨다.
• 예측 가능한 변경으로 인해 여러 클래스가 불안정해진다면 PROTECTED VARIATIONS 패턴에 따라 안정적인 인터페이스 뒤로 변경을 캡슐화한다.

🎈 변경과 유연성

• 설계를 주도하는 것은 변경이다. 개발자로서 변경에 대비할 수 있는 두 가지 방법이 있다. 하나는 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계하는 것이다. 다른 하나는 코드를 수정하지 않고도 변경을 수용할 수 있도록 코드를 더 유연하게 만드는 것이다.
• 유사한 변경이 반복적으로 발생하고 있다면 복잡성이 상승하더라도 유연성을 추가하는 두 번째 방법이 더 좋다. (상속 대신 합성을 사용하자.) 요소들 사이의 의존성의 정도가 유연성의 정도를 결정한다.

📚 책임 주도 설계의 대안

• 책임과 객체 사이에서 방황할 때 돌파구를 찾기 위해 선택하는 방법은 최대한 빠르게 목적한 기능을 수행하는 코드를 작성하는 것이다. 아무것도 없는 상태에서 책임과 협력에 관해 고민하기보다는 일단 실행되는 코드를 얻고 난 후 코드 상에 명확하게 드러나는 책임들을 올바른 위치로 이동시키는 것이다.
• 주의할 점은 코드를 수정한 후에 겉으로 드러나는 동작이 바뀌어서는 안 된다. 캡슐화를 향상시키고, 응집도를 높이고, 결합도를 낮춰야 하지만 동작은 그대로 유지해야 한다. 이처럼 이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해 겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것을 리팩터링이라고 부른다.

🎈 메서드 응집도

• 데이터 중심으로 설계된 영화 예매 시스템에서 도메인 객체들은 단지 데이터의 집합일 뿐이며 영화 예매를 처리하는 모든 절차는 ReservationAgency에 집중돼 있었다. 따라서 ReservationAgency에 포함된 로직들을 적절한 객체의 책임으로 분배하면 책임 주도 설계와 거의 유사한 결과를 얻을 수 있다.
• 한마디로 말해서 긴 메서드는 응집도가 낮기 때문에 이해하기도 어렵고 재사용하기도 어려우며 변경하기도 어렵다. 마이크 페더스는 이런 메서드를 몬스터 메서드(monster method)라고 부른다.
• 응집도가 높은 메서드는 변경되는 이유가 단 하나여야 한다. 클래스가 작고, 목적이 명확한 메서드들로 구성돼 있다면 변경을 처리하기 위해 어떤 메서드를 수정해야 하는지를 쉽게 판단할 수 있고 메서드의 크기가 작고 목적이 분명하기 때문에 재사용하기도 쉽다.

🎈 객체를 자율적으로 만들자

• 자신이 소유하고 있는 데이터를 자기 스스로 처리하도록 만드는 것이 자율적인 객체를 만드는 지름길이다. 따라서 메서드가 사용하는 데이터를 저장하고 있는 클래스로 메서드를 이동시키면 된다.
• 어떤 데이터를 사용하는지를 가장 쉽게 알 수 있는 방법은 메서드 안에서 어떤 클래스의 접근자 메서드를 사용하는 파악하는 것이다.