TIL

05 책임 할당하기

• 데이터 중심 설계로 인해 발생하는 문제는 책임에 초점을 맞추면 해결할 수 있다.
• 이번 장에서는 객체에 책임을 할당하는 기본 원리를 살펴보자

01 책임 주도 설계를 향해

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

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

• 데이터는 객체가 책임을 수행하는 데 필요한 재료를 제공할 뿐
• 너무 이른 시기에 데이터에 초점을 맞추면 캡슐화가 약화된다.
• 객체지향 설계에서 가장 중요한 것은 적절한 객체에게 적절한 책임을 할당하는 능력
• 협력의 관점에서 객체에 할당할 책임을 알 수 있다.

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

• 객체의 책임 품질은 협력에 적합한 정도로 결정된다.
  • 협력에 어울리지 않으면 나쁜 책임
  • 객체 입장에서 어색하더라도 협력에 적합하다면 좋은 책임
• 객체가 메시지를 선택하는 것이 아닌 메시지가 객체를 선택해야 한다.
  • 협력에 적합한 책임을 위해
• 메시지를 먼저 결정하기 때문에 메시지 송신자는 메시지 수신자에 대해 어떠한 가정도 할 수 없다.
  • 메시지 전송자 관점에서 수신자가 깔끔하게 캡슐화된다.
• 즉 책임 중심 설계에서는 협력이라는 문맥 안에서 객체가 수행할 책임에 초점을 맞춘다.

책임 주도 설계

• 책임 주도 설계 흐름
  • 시스템이 사용자에게 제공하는 기능인 시스템 책임 파악
  • 시스템 책임을 더 작은 책임으로 분할
  • 분할된 책임을 수행할 객체 또는 역할을 찾아 할당
  • 객체가 책임 수행 도중 다른 객체의 도움이 필요한 경우 이를 책임질 객체 또는 역할을 탐색
  • 해당 객체 또는 역할에 책임을 할당함으로써 두 객체가 협력
• 협력에 참여하는 객체들은 책임이 어느 정도 정리될 때까지는 객체 내부 상태에 관심을 가지지 않는다.

02 책임 할당을 위한 GRASP 패턴

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

도메인 개념에서 출발하기

• 설계 시작 전에 도메인에 대한 개략적 모습을 그려 보는 것이 유용하다.
  • 책임을 할당할 때 가장 먼저 고민해야 하는 유력 후보가 바로 도메인 개념
  • 도메인 개념 그림을 통해 도메인 간 1:1 관계, 1:N 관계 등을 쉽게 파악할 수 있다.
• 이러한 도메인 개념은 단지 출발점일 뿐이다.
  • 완벽하게 개념 의미와 관계가 정확하고 완벽하지 않아도 된다.
  • 설계를 위해 참고할 수 있는 개념 모음 정도로 간주하라

올바른 도메인 모델이란 존재하지 않는다. 위의 영화 시스템 도메인 모델도 2장에서 설명한 모델과 다르다. 올바른 구현을 이끌어낼 수 있다면 정답을 둘 다 올바르다. 이번 장의 마지막에 이르면 도메인 모델이 2장과 동일하게 변경되는데 이는 유연성과 재사용성을 고려하며 얻게 되는 통찰이 역으로 도메인에 대한 개념을 바꾸기 때문이다. 중요한 것은 도메인을 그대로 투영한 모델이 아닌 구현에 도움이 되는 모델이다.

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

• 책임 주도 설계 첫 단계는 시스템 책임을 메시지로 간주하고 이 메시지를 책임질 첫 객체를 선택하는 것이다.
• 책임을 통해 메시지를 결정하고, 메시지는 메시지를 수신할 객체가 아닌 전송할 객체의 의도를 반영해서 결정해야 한다.
  • ex) ‘영화를 예매하는 것’ 책임을 통해 메시지 전송자 입장에서 ‘예매하라’라는 메시지를 도출할 수 있다.
• 메시지를 결정한 후에는 메시지를 수신할 객체를 선택해야 한다.
  • 수신 객체를 선택하기 위해선 객체가 스스로 상태를 처리하는 자율적인 존재라는 점에 주목해야 한다.
  • 즉 책임 할당의 첫 원칙은 책임을 수행할 정보를 알고 있는 객체에게 할당하는 것이다.
  • 이를 INFORMATION EXPERT 패턴이라 부른다.
  • ex) 상영 도메인은 영화의 정보와 상영 시간 등의 정보를 알고 있기에 ‘예매하라’ 책임을 할당하기 적합하다.

INFORMATION EXPERT 패턴이란 객체가 자신이 소유한 정보와 관련된 작업을 수행한다는 일반적인 직관을 표현한 패턴이다. 다만 ‘정보’ ‘데이터’는 다른데 객체가 정보를 알고 있다고 해서 그 정보를 ‘저장’할 필요는 없기 때문이다. 정보를 굳이 저장하지 않고 계산 등을 통해서도 도출할 수 있다.

• 메시지가 객체에 할당되었다면 이제는 외부 인터페이스가 아닌 내부로 들어가 메시지 처리를 위한 절차와 구현을 고민해야 한다.
  • 세세한 구현 보다는 책임 수행에 필요한 작업과 처리할 수 없는 작업이 무엇인지 가릴 정도면 된다.
• INFORMATION EXPERT 패턴에 따라 영화 시스템의 책임 할당 예시
  • ‘예매하라’ 완수를 위해 예매 가격을 계산해야 하기에 상영을 이를 가지고 있는 정보로 계산할 것이다.
  • 하지만 영화 한 편 가격을 알아야 하는데 이는 모르기에 외부 객체에게 도움을 얻어 가격을 얻어야 한다.
  • 상영이 메시지 송신자로서 새로운 메시지인 ‘계산하라’를 도출하게 된다.
  • INFORMATION EXPERT 패턴에 따라 영화 도메인에게 ‘계산하라’가 할당될 것이다.
  • 영화의 구현을 개략적으로 생각했을 때 할인이 가능한지를 판단해야 하는데 이 또한 외부에 도움의 필요하다.
  • ‘할인 여부를 판단하라’ 메시지가 도출되고 이 메시지를 처리할 정보 전문가는 할인 조건이다.
  • 할인 조건은 할인 여부 판단에 대해 외부 정보를 필요로하지 않기에 메시지를 전송하지는 않는다.

• 이처럼 INFORMATION EXPERT 패턴을 통해 자율성이 높은 객체들로 구성된 협력 공동체를 구축할 가능성이 높아진다.

    '예매하라' 
        |
    Screening - '계산하라' -> Movie 
                              |
                     '할인 여부를 판단하라' -> DiscountCondition
  

높은 응집도와 낮은 결합도

• 설계는 트레이드오프 활동이기에 INFORMATION EXPERT 패턴 이외의 다른 패턴을 고려할 필요도 있다.

• INFORMATION EXPERT 패턴 설계의 대안으로 영화 예제에서 다른 설계를 고려할 수도 있다.

    '예매하라' 
        |
    Screening - '계산하라' -> Movie 
        |
    '할인 여부를 판단하라' -> DiscountCondition
  

  • 영화가 할인 조건과 협력하는 것이 아닌 상영이 ‘할인 조건’과 협력할 수도 있다.
  • 기능 측면에선 동일한 행동을 하지만 차이점은 할인 조건과 협력하는 객체가 영화가 아니라 상영이라는 것
  • 어떤 객체끼리의 협력을 구성할지에 대해선 응집도와 결합도의 측면에서 생각해봐야 한다.
• GRASP에선 낮은 결합도와 높은 응집도에 대해 LOW COUPLING 패턴과 HIGH COHESION 패턴이라 부른다.
• LOW COUPLING 패턴의 관점
  • 도메인 개념 설계를 보면 영화는 이미 할인 조건의 목록을 속성으로 포함하고 있다.
  • 기존 설계대로면 상영에 할인 조건 결합을 추가하지 않고도 협력을 완성할 수 있다.
  • 즉 LOW COUPLING 관점에선 영화가 할인 조건과 협력하는 것이 더 나은 설계 대안이다.
• HIGH COHESION 패턴 관점
  • 상영의 핵심 책임은 예매하는 것이다.
  • 그런데 할인 조건과 협력한다면 요금 계산과 관련된 책임 일부를 맡아야 한다.
  • 즉 요금 계산 방식이 변경될 경우 상영도 함께 변경해야 한다.
  • 영화는 원래부터 요금 계산이 핵심 책임이기에 할인 조건 판단을 위해 할인 조건과 협력하는 것은 응집에 해를 끼치지 않는다.

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

• GRASP의 CREATOR 패턴
  • 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침 제공
  • 영화 예매 협력의 최종 결과물은 Reservation 인스턴스를 생성하는 것이고 Screening이 그 책임을 맡았다.
• CREATOR 패턴에선 객체 A를 생성할 때 아래 조건을 가장 많이 만족하는 B에게 생성 책임을 할당하라고 한다.
  • B가 A를 포함하거나 참조한다.
  • B가 A를 기록한다.
  • B가 A를 긴밀하게 사용한다.
  • B가 A를 초기화하는 데 필요한 데이터를 가지고 있다.
    • B는 A에 대한 정보 전문가인 경우

CREATOR 패턴의 의도는 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체 생성 책임을 맡기는 것. 이미 결합돼 있는 객체에게 생성 책임을 할당하는 것은 전체적인 결합도에 영향을 미치지 않는다.

03 구현을 통한 검증

• Screening

    public class Screening {
        private Movie movie;
        private int sequence;
        private LocalDateTime whenScreened;
      
        // '예매하라' 메시지 시그니처
        // Reservation 인스턴스 생성
        public Reservation reserve(Customer customer, int audienceCount) {
            return new Reservation(customer, this, calculateFee(audienceCount), audienceCount);
        }
      
        private Money calculateFee(int audienceCount) {
            return movie.calculateMovieFee(this).times(audienceCount);
        }
    }
  

  • Movie에 ‘계산하라’ 메시지 시그니처로 calculateMovieFee(Screening screening) 선언
    • Movie 내부 구현을 고려하지 않고 메시지로 캡슐화

• Movie

    public class Movie {
        private String title;
        private Duration runningTime;
        private Money fee;
        private List<DiscountCondition> discountConditions;
      
        private MovieType movieType;
        private Money discountAmount;
        private double discountPercent;
      
        // '계산하라' 메시지 시그니처
        public Money calculateMovieFee(Screening screening) {
            if (isDiscountable(screening)) {
                return fee.minus(calculateDiscountAmount());
            }
            return fee;
        }
      
        // 할인 여부 판단
        private boolean isDiscountable(Screening screening) {
            return discountConditions.stream()
                    .anyMatch(condition -> condition.isSatisfiedBy(screening));
        }
      
        private Money calculateDiscountAmount() {
            switch(movieType) { // MovieType에 따라 할인 정책 적용
                case AMOUNT_DISCOUNT:
                    return calculateAmountDiscountAmount();
                case PERCENT_DISCOUNT:
                    return calculatePercentDiscountAmount();
                case NONE_DISCOUNT:
                    return calculateNoneDiscountAmount();
            }
      
            throw new IllegalStateException();
        }
      
        private Money calculateAmountDiscountAmount() {
            return discountAmount;
        }
      
        private Money calculatePercentDiscountAmount() {
            return fee.times(discountPercent);
        }
      
        private Money calculateNoneDiscountAmount() {
            return Money.ZERO;
        }
    }
  

  • DiscountCondition에 ‘할인 여부를 판단하라’ 메시지 시그니처로 isSatisfiedBy(Screening screening) 선언

• DiscountCondition

    public class DiscountCondition {
        private DiscountConditionType type;
        private int sequence;
        private DayOfWeek dayOfWeek;
        private LocalTime startTime;
        private LocalTime endTime;
      
        public boolean isSatisfiedBy(Screening screening) {
            if (type == DiscountConditionType.PERIOD) {
                return isSatisfiedByPeriod(screening);
            }
      
            return isSatisfiedBySequence(screening);
        }
      
        private boolean isSatisfiedByPeriod(Screening screening) {
            return dayOfWeek.equals(screening.getWhenScreened().getDayOfWeek()) &&
                    startTime.compareTo(screening.getWhenScreened().toLocalTime()) <= 0 &&
                    endTime.compareTo(screening.getWhenScreened().toLocalTime()) <= 0;
        }
      
        private boolean isSatisfiedBySequence(Screening screening) {
            return sequence == screening.getSequence();
        }
    }
  

  • 순번 할인 조건인지 기간 할인 조건인지에 따라 할인 여부 판단
  • DiscountCondition은 할인 조건 판단을 위해 Screening 상영 시간과 상영 순번을 알아야 하기에 Screening이 이를 제공해야 한다.
    • Screening에 getWhenScreend()와 getSequence() 추가 필요

DiscountCondition 개선하기

• DiscountCondition은 다음 서로 다른 세 가지 이유로 변경될 수 있다.
  • 새로운 할인 조건 추가
  • 순번 조건 판단 로직 변경
  • 기간 조건 판단 로직 변경
• 하나 이상의 변경 이유를 가지기 때문에 응집도가 낮다.
  • 때문에 서로 다른 시점에 변경될 확률이 높다.
  • 즉변경 이유에 따라 클래스를 분리해야 한다.
• 코드로 변경 이유를 파악할 수 있는 방법
  • 인스턴스 변수가 초기화 되는 시점 살피기
    • 응집도 높은 클래스는 인스턴스 생성 시 모든 속성을 함께 초기화한다.
    • 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다.
  • 메서드들이 인스턴스 변수를 사용하는 방식 살피기
    • 모든 메서드가 객체의 모든 속성을 사용한다면 응집도가 높다.
    • 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다.

타입 분리하기

• DiscountCondition의 가장 큰 문제는 두 독립적 타입이 한 클래스에 공존하는 것
  • 순번 조건, 기간 조건

• 각 조건을 SequenceCondition과 PeriodCondition 두 클래스로 분리할 수 있다.

    public class SequenceCondition {
        private int sequence;
      
        public SequenceCondition(int sequence) {
            this.sequence = sequence;
        }
      
        public boolean isSatisfiedBy(Screening screening) {
            return sequence == screening.getSequence();
        }
    }
      
    public class PeriodCondition {
        private DayOfWeek dayOfWeek;
        private LocalTime startTime;
        private LocalTime endTime;
      
        public PeriodCondition(DayOfWeek dayOfWeek, LocalTime startTime, LocalTime endTime) {
            this.dayOfWeek = dayOfWeek;
            this.startTime = startTime;
            this.endTime = endTime;
        }
      
        public boolean isSatisfiedBy(Screening screening) {
            return dayOfWeek.equals(screening.getWhenScreened().getDayOfWeek()) &&
                    startTime.compareTo(screening.getWhenScreened().toLocalTime()) <= 0 &&
                    endTime.compareTo(screening.getWhenScreened().toLocalTime()) >= 0;
        }
    }
  

  • 각 Condition은 자신의 모든 인스턴스 변수를 함께 초기화할 수 있다.
  • 클래스의 모든 메서드는 동일한 인스턴스 변수 그룹을 사용한다.
  • 하지만 Movie와 협력하는 클래스는 DiscountCondition 하나 뿐이었기에 위 두 클래스와 모두 협력할 수 있어야 한다.

• Movie 클래스 안에 SequenceCondition, PeriodCondition 목록을 따로 유지하는 방법이 있다.

    public class Movie {
        // ...
      
        private List<PeriodCondition> periodConditions;
        private List<SequenceCondition> sequenceConditions;
      
        // ...
      
        private boolean checkPeriodConditions(Screening screening) {
            return periodConditions.stream()
                    .anyMatch(condition -> condition.isSatisfiedBy(screening));
        }
      
        private boolean checkSequenceConditions(Screening screening) {
            return sequenceConditions.stream()
                    .anyMatch(condition -> condition.isSatisfiedBy(screening));
        }
  

  • Movie가 SequenceCondition, PeriodCondition 양쪽 모두에게 결합되는 문제
  • 새로운 할인 조건을 추가하기가 더 까다로워졌다.
    • List 변수를 추가해야 하고 메서드도 추가해야한다.
  • 응집도는 높아졌지만 변경과 캡슐화라는 관점에선 설계 품질이 나빠진 것

다형성을 통해 분리하기

• 이 시점에 ‘역할’이라는 개념이 등장한다.
  • Movie 입장에선 SequenceCondition, PeriodCondition은 동일한 책임을 수행한다.
  • 역할은 협력 안에서 대체 가능성을 의미하기에 구체 타입은 알지 못한 채 오직 역할에만 의존하도록 제한할 수 있다.
• 자바에선 역할을 구현할 때 추상 클래스나 인터페이스를 사용한다.
  • 역할을 대체할 구체 타입들이 구현을 공유해야 할 필요가 있다면 추상 클래스 사용
  • 구현을 공유할 필요가 없다면 인터페이스를 사용

• Movie가 DiscountCondition 역할 의존하도록 변경

    public interface DiscountCondition {
        boolean isSatisfiedBy(Screening screening);
    }
  

    public class Movie {
        // ...
        private List<DiscountCondition> discountConditions;
        // ...
      
        public Money calculateMovieFee(Screening screening) {
            if (isDiscountable(screening)) {
                return fee.minus(calculateDiscountAmount());
            }
            return fee;
        }
      
        private boolean isDiscountable(Screening screening) {
            return discountConditions.stream()
                    .anyMatch(condition -> condition.isSatisfiedBy(screening));
        }
  

  • Movie는 구체 타입을 몰라도 역할이 올바른 메시지를 받아들일 수 있다는 사실만 알아도 충분하다.
• POLYMORPHISM(다형성) 패턴
  • 객체 타입을 검사해서 타입에 따라 여러 대안을 수행하는 조건적인 논리를 사용하지 말라고 경고 (if ~ else, switch ~ case)
  • 다형성을 통해 변화를 다루기 쉽게 확장하라고 권고한다.

변경으로부터 보호하기

• DiscountCondition의 두 서브클래스는 서로 다른 이유로 변경된다.
  • 두 구체 타입의 변경은 서로의 클래스 안으로 캡슐화된다.
• 새로운 할인 조건이 추가되어도 Movie는 알지 못한다.
• PROTECTED VARIATIONS (변경 보호) 패턴
  • 변경을 캡슐화하도록 책임을 할당하는 것
• 클래스를 변경에 따라 분리하고 인터페이스로 변경을 캡슐화하는 것은 결합도와 응집도를 높이는 매우 강력한 방법이다.

Movie 클래스 개선하기

• Movie 클래스 또한 금액 할인 정책과 비율 할인 정책 영화라는 두 타입을 한 클래스에서 구현하고 있기에 응집도가 낮다.
• POLYMORPHISM 패턴으로 다형성을 적용하고 PROTECTED VARIATIONS 패턴을 통해 타입 종류를 캡슐화하자.

  • Movie의 경우 구현을 공유해야 해서 추상 클래스를 사용

    public abstract class Movie {
        private String title;
        private Duration runningTime;
        private Money fee;
        private List<DiscountCondition> discountConditions;
        
        public Movie(String title, Duration runningTime, Money fee, DiscountCondition... discountConditions) {
            this.title = title;
            this.runningTime = runningTime;
            this.fee = fee;
            this.discountConditions = Arrays.asList(discountConditions);
        }
        
        public Money calculateMovieFee(Screening screening) {
            if (isDiscountable(screening)) {
                return fee.minus(calculateDiscountAmount());
            }
        
            return fee;
        }
        
        private boolean isDiscountable(Screening screening) {
            return discountConditions.stream()
                    .anyMatch(condition -> condition.isSatisfiedBy(screening));
        }
        
        protected Money getFee() {
            return fee;
        }
        
        abstract protected Money calculateDiscountAmount();
    }
    

  • 원래 있었던 discountAmount, discountPercent 변수가 사라졌다.
  • 할인 금액을 계산하는 메서드가 추상 메서드가 되었다.
  • AmountDiscountMovie와 PercentDiscountMovie 구체 타입에서 각 변수와 메서드를 추가 또는 오버라이딩할 수 있다.

도메인 구조가 코드의 구조를 이끈다. 도메인 모델은 단순히 설계에 필요한 용어를 제공하는 것을 넘어 구조에 영향을 미친다. 변경 역시 도메인 모델의 일부이다. 도메인 모델에는 도메인 안에서 변하는 개념과 이들 사이 관계가 투영되어 있어야 한다. 위 도메인 모델에서도 할인 정책과 조건이 변경될 수 있다는 직관이 반영되어 있다.

변경과 유연성

• 설계를 주도하는 것은 변경이다.
• 변경에 대비하는 두 가지 방법
  • 코드를 이해하고 수정하기 쉽도록 최대한 단순하게 설계
  • 코드를 더 유연하게 설계
• 추상 클래스와 상속으로 구현한 Movie의 문제점
  • 실행 중에 할인 정책을 변경하기 위해선 새 인스턴스를 생성 후 필요한 정보를 복사해야 한다.
  • 변경 전 후 인스턴스가 개념적으로는 같지만 물리적으로는 다르기에 식별자 관점에서 혼란스럽다.
• 상속 대신 합성을 사용

  • Movie 상속 계층 안에 구현된 할인 정책을 독립적인 DiscountPolicy로 분리 후 Movie에 합성

    Movie movie = new Movie("타이타닉", 
                            Duration.ofMinutes(120),
                            Money.wons(10000),
                            new AmountDiscountPolicy(...));
    movie.changeDiscountPolicy(new PercentDiscountPolicy(...)); 
    

  • 합성을 사용하면 새 정책이 추가되더라도 정책 변경 시 추가적인 코드를 작성할 필요가 없다.

04 책임 주도 설계의 대안

• 책임 주도 설계에 익숙해지려면 노력과 시간이 필요하다.
• 책임과 객체 사이에서 방황할 때 돌파구를 찾기 위해서 선택하는 방법은 최대한 빠르게 목적한 기능을 수행한 코드를 작성하는 것
  • 우선 코드를 작성하고 책임들을 올바른 위치로 이동시켜라
  • 주의할 점은 수정 전후로 동작이 바뀌어서는 안 된다.
• 리팩터링 (Refactoring)
  • 이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해 겉으로 보이는 동작은 바꾸지 않고 내부 구조를 변경하는 것

메서드 응집도

• 일단 기능을 수행하는 코드를 절차적으로 작성할 수 있다.
• 절차지향적이고 긴 메서드(몬스터 메서드)는 유지보수에 부정적 영향을 끼친다.
  • 어떤 일을 수행하는지 한 눈에 파악하기 어렵다.
  • 변경이 필요할 때 수정할 부분을 찾기 어렵다.
  • 메서드 내부 일부 로직만 수정하도라도 메서드 나머지 부분에서 버그가 발생할 확률이 높다.
  • 로직 일부만 재사용하는 것이 불가능
  • 코드를 재사용하는 유일한 방법은 복붙뿐이므로 코드 중복을 초래한다.
  • 로직 흐름을 이해하기 어렵기에 주석이 필요한 경우가 대부분
• 메서드를 잘게 쪼갰을 때의 장점
  • 메서드가 작으면 다른 메서드에서 사용될 확률이 높아진다.
  • 고수준 메서드를 볼 때 일련의 주석을 읽는 것 같은 느낌이 들게 할 수 있다.
  • 오버라이딩하는 것도 훨씬 쉽다.
  • 전체적인 흐름을 이해하기도 쉬워진다.
  • 변경하기 쉽다.

객체를 자율적으로 만들자

• 메서드를 쪼갰다면 이제 클래스를 나눠야 한다.
• 자신이 소유하는 데이터를 자기 스스로 처리하도록 만드는 것이 자율적 객체를 만드는 지름길이다.
  • 클래스의 접근자 메서드를 파악하면 어떤 데이터를 사용하는지 쉽게 알 수 있다.
• 처음부터 책임 주도 설계를 따르는 것보다 동작하는 코드를 작성한 후 리팩터링하는 것이 더 훌륭한 결과물을 낳을 수도 있다.