오브젝트 5장

제 5장

책임 할당하기

책임 주도 설계를 향해

데이터 중심의 설계에서 책임 중심의 설계로 전환하라

• 데이터보다 행동을 먼저 결정하라
• 협력이라는 문맥안에서 책임을 결정하라
• “메시지를 전송해야 하는데 누구에게 전송해야 하지?”를 고민하라
• 책임 주도 설계 흐름
  • 시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악
  • 시스템 책임을 더 작은 책임으로 분할
  • 분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당
  • 객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 만한 객체 또는 역할을 찾음
  • 해당 객체 또는 역할에게 책임을 할당하게 함으로써 두 객체가 협력하게 함

책임 할당을 위한 GRASP 패턴

General Responsibility Assignment Software Pattern ( 일반적인 책임 할당을 위한 소프트웨어 패턴 )

설계의 과정에서 계속해서 질문을 던지자

• 메시지를 전송할 객체는 무엇을 원하는가?
• 메시지를 수신할 적합한 객체는 누구인가?
• INFORMATION EXPERT 패턴
  • 책임을 정보 전문가, 책임을 수행하는 데 필요한 정보를 가지고 있는 객체에게 할당하라
  • 객체는 자율적인 존재여야 한다.
  • 정보와 행동을 최대한 가까운 곳에 위치시켜 캡슐화를 유지해야한다.
  • 관련 책임을 가장 많이 알고 있는 객체에게 메시지를 처리할 책임을 할당시키는 것이 INFORMATION EXPERT 패턴
• LOW COUPLING 패턴
  • 낮은 결합도를 위한 설계 패턴 방식
  • 어떻게 하면 의존성을 낮추고 변화의 영향을 줄이고 재사용 성을 높일 수 있을지?
• HIGH COHESION 패턴
  • 높은 응집도를 위한 설계 패턴 방식
  • 어떻게 복잡성을 관리할 수 있는 수준으로 유지할 것인가?
• CREATOR 패턴
  • 객체 A를 생성할 때 어떤 객체에게 객체 생성 책임을 할당해야 하는가에 대한 패턴, 아래의 조건을 최대한 만족하는 B에게 A 객체 생성 책임을 할당
  • B가 A 객체를 포함하거나 참조
  • B가 A 객체를 기록
  • B가 A 객체를 긴밀하게 사용
  • B가 A 객체를 초기화하는 데 필요한 데이터를 가진 경우 ( 이 경우 B는 A에 대한 정보 전문가 )
• POLYMORPHISM 패턴
  • 객체의 타입에 따라 변하는 로직이 있을 때 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당
  • if ~ else, switch ~ case 등의 조건 논ㄴ리를 사용해 설계하면 새로운 변화가 일어난 경우 조건 논리를 수정해야 함
  • POLYMORPHISM 패턴은 객체의 타입을 검사해 타입에 따라 여러 대안을 수행하는 조건적인 논리를 사용하지 말것을 경고하고 있다.
  • 다형성을 이용해 변화를 다루기 쉽게 확장할 것을 권고하는 패턴
• PROTECTED VARIATIONS 패턴
  • 객체, 서브시스템, 시스템이 변화와 불안정성으로 인해 다른 요소에 나쁜 영향을 미치지 않게 할 수 있는 설계 패턴
  • 책임 할당의 간점에서 캡슐화를 설명한 것
  • “설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화 하라”는 PROTECTED VARIATIONS의 본질과 같다.
• 객체지향 디자인의 기본은 책임을 어디에 둘 지 결정하는 것
• 만약 처음부터 RDD가 힘들다면 리팩터링 과정을 거치는 것도 좋은 방법, 이로 인해 더 좋은 설계를 얻을 수 도 있음

Reference

오브젝트 - 조영호