[오브젝트] 5장 - 책임 할당하기
    2022-09-19 10:00
    object

    책임 중심 설계

    • 어떤 객체에게 어던 책임을 할당할지 결정해야한다

    • 문제 해결을 위한 다양한 책임 할당 방법이 존재하며 일종의 트레이드오프 활동이다.

    • 상황과 문맥에 따라 최적의 책임 할당 방법을 선택해야한다.

    • 책임 중심 설계를 위한 원칙

      • 데이터보다 행동을 먼저 결정
        • 중요한 것은 데이터가 아닌 외부에 제공하는 행동 (객체의 책임)
        • 객체가 수행해야 하는 책임이 무엇인지 결정 후, 책임을 수행하는 데 필요한 데이터를 결정
      • 협력이라는 문맥 안에서 책임을 결정
        • 객체 책임의 품질은 협력에 적합한 정도로 결정된다.
        • 책임은 객체 입장이 아니라 객체가 참여하는 협력에 적합해야 한다.
        • 메시지를 전송하는 클라이언트의 의도에 적합한 책임을 할당하라.
        • 메시지가 객체를 선택하게 하라.

    • 메시지를 전송해야 하는데 누구에게 전송해야 하지? 라고 질문

      • -> 메세지 기반 설계

    • 객체를 결정하기 전에 객체가 수신할 메시지를 먼저 결정

      • -> 송신자 관점에서 수신자가 캡슐화됨

    책임 할당 GRASP 패턴

    • 설계 시작시 도메인을 책임 할당의 대상으로 사용하라. (도메인 모델 그리기)
      • 개념들의 의미와 관계가 완벽할 필요 없다.
      • 도메인 개념 정리에 시간투자 X. 설계를 시작하기 위한 개념들의 모음이면 충분
    • 어플리케이션이 제공해야하는 기능 -> 어플리케이션의 책임
    • 책임을 어플리케이션에 대해 전송된 메시지로 간주
      • 메시지를 책임질 첫 번째 객체를 선택하는것으로 책임 주도 설계 시작

    Information Expert 패턴

    • 책임을 수행할 정보를 알고 있는 객체에게 책임을 할당하라.
      • 객체의 책임과 책임을 수행하는데 필요한 상태는 동일한 객체 안에 존재해야 한다.
      • 정보와 행동이 가까이 있으면 캡슐화 유지됨 (응집도 높이고 결합도 낮추고)

    Low Coupling & High Cohesion 패턴

    • 책임을 할당할 수 있는 다양한 대안이 존재한다면 응집도와 결합도 측면에서 더 나은 대안을 선택.

    Creator 패턴

    • 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공

    • 객체 A를 생성해야 할 때 아래 조건을 최대한 만족하는 B에게 생성 책임을 할당

      • B가 A 객체를 포함하거나 참조
      • B가 A 객체를 기록
      • B가 A 객체를 긴밀히 사용
      • B가 A에 대한 정보 전문가다

    • 클래스 응집도 판단하는 방법 (변경의 이유가 하나 이상인 클래스를 찾는 방법)

      • 변경의 이유를 기준으로 클래스를 분리하라 (SRP)
      • 클래스의 인스턴스를 초기화하는 시점에 경우에 따라 서로 다른 속성들을 초기화하고 있다면 응집도가 낮다는 증거
      • 메서드 그룹이 속성 그룹을 사용하는지 여부로 나뉜다면 응집도가 낮다는 증거

    Polymorphism 패턴

    • 타입을 명시적으로 정의하고 각 타입에 다형적으로 행동하는 책임을 할당하라.
      • 조건문을 사용해 설계하면 변경에 취약한 설계가 된다.
      • 다형성을 이용해 변화를 다루기 쉽게 확장하라

    Protected Varations 패턴

    • 변경될 가능성이 높다면 캡슐화하라.

      • 클래스를 변경에 따라 분리하고 인터페이스를 이용해 변경을 캡슐화하라
      • 결합도와 응집도 향상

    • 처음부터 책임 주도 설계를 따르는 것보다 동작하는 코드를 먼저 작성하고 리팩터링하는 것이 더 훌륭한 결과물을 낳을 수 있다.

      • 객체로 책임을 분배할 때 메서드를 응집도 있는 수준으로 분해하라
      • 자신이 소유하고 있는 데이터를 스스로 처리하도록 메서드를 알맞는 클래스에 배치하라
        • 메서드를 다른 클래스로 이동시킬 때는 인자에 정의된 클래스 중 하나로 이동하는게 일반적

    느낀점

    책임주도 설계를 잘하기란 정말 어렵다. 때문에 책에서도 언급되었듯이 동작하는 코드를 먼저 작성하고 나서 책임주도 설계로 리팩터링 해나가고는 한다.

    하지만 코드의 스멜을 찾기는 생각보다 어려울 수 있고 리팩터링으로 인한 트레이드 오프를 개발자가 인지하지 못 할 수도 있다.

    이러한 이유에서 코드리뷰 문화는 코드의 품질을 높이는데 중요한 요소라고 생각하며 선한 피드백을 주고 받을 수 있는 동료가 될 수 있도록 노력하고 그러한 환경을 만드는데 기여해야겠다.