Chapter 5. 책임 할당하기

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다.

---

책임 주도 설계

 

데이터를 중심으로 설계하게되면 유연한 설계를 하기 힘들다.

 

애초에, '데이터' 라는 것은 객체의 구체적인 정보이고, 이는 구현에 해당한다.

 

따라서, 데이터 중심적 설계는 객체의 구현부에 초점을 맞추고 설계 한다는 의미이다.

 

그리고, 데이터를 중점으로 객체 간 협력을 생각하게 되면 외부 객체에게 자신의 데이터 정보를 넘겨주는 것이므로 캡슐화를 방해하게된다.

 

결과적으로, 구현을 중점으로한 설계는 캡슐화를 저해하고 응집도는 낮추고 결합도는 높임으로서 변화에 취약한 설계가 된다.

 

💡 따라서, 객체 지향의 핵심인 협력, 책임, 역할 중 가장 중요한 책임 을 중점으로 설계하는 것이 유연한 설계를 할 수 있게 해준다.

 

[ 객체가 포함해야하는 데이터는 무엇인가 → 이 데이터를 활용할 수 있는 협력은 무엇인가] 를 생각하는 것이 아닌

 

[ 객체가 다른 객체에게 제공해야하는 행동은 무엇인가 → 그 행동을 하기 위해 필요한 데이터는 무엇인가] 를 생각해야한다.

 

 

책임 할당을 위한 GRASP 패턴

 

GRASP (General Responsibility Assignment Software Pattern)은 책임을 할당할 떄 지침으로 삼을 수 있는 원칙들을 정리한 것이다.

 

1️⃣ Information Expert 패턴

💡 책임을 수행할 정보를 알고 있는 객체에게 책임을 부여한다는 원칙이다.

 

영화 예매 서비스가 있다고 했을 때,

 

영화를 예매해라 라는 책임은 어떤 객체가 적절할까? 고민하고 책임을 부여한다.

 

영화 상영 시작 시간과 회차 등에 대한 정보를 갖는 '상영' 객체가 가장 잘 처리할 수 있을 것 같다.

 

영화 예매를 위해 가격을 계산해야하는데,  영화 가격을 계산하라 라는 책임은 또 어떤 객체가 적절할까? 고민하고 책임을 부여한다.

 

영화 가격에 대한 정보는 '영화' 객체가 영화에 대한 정보를 갖고 있으므로 가장 잘 처리할 수 있을 것 같다.

 

이처럼, 어떤 책임을 정하고, 그 책임에 대한 정보를 가장 많이 알고 있어서 잘 수행할 수 있을 객체를 결정하고 책임을 부여하는 방식이다.

 

2️⃣ Low Coupling 패턴

 💡 설계의 전체적인 결합도가 낮게 유지되도록 책임을 부여한다는 원칙이다.

 

'상영' 은 '영화' 를 알고 있고 '영화' 는 '할인조건' 을 알고있다.

 

이때, '상영' 이 '영화' 에게 [영화 가격을 계산해라] 라는 책임을 요청하면, '영화' 는 '할인조건' 과 협력하여 할인가를 계산한 뒤 응답한다.

 

'상영' 이 '할인조건' 과 직접 협력하여 할인 정보를 구한 뒤, '영화' 에게 가격을 계산하라고도 할 수 있지만

 

이 경우, '상영'과 '할인조건' 의 결합 관계가 추가된다.

 

따라서, 이미 '영화' 와 '할인조건' 은 결합된 상태이기 때문에 결합 관계를 추가하지 않고 협력할 수 있도록 하는 것을 지향하면 결합도를 낮출 수 있다.

 

3️⃣ High Cohesion 패턴

💡 높은 응집도를 유지할 수 있게 책임을 부여한다는 원칙이다.

 

 '상영'과 '할인조건' 이 협력하고 있는 관계라면

 

'할인조건' 에 변경이 발생한 경우 '영화' 와 '상영' 둘 다 영향을 받게 된다.

 

4️⃣ Creator 패턴

영화 예매 서비스의 경우

 

최종적으로 생성해야하는 객체는 예매 정보를 담은 '예매' 객체이다.

 

'예매' 객체를 가장 잘 생성할 수 있는 객체(창조자)를 찾고 그 객체에게 책임을 할당하는 것이다.

 

'영화' 가 '예매' 객체를 가장 잘 생성할 수 있을까?

 

'영화' 는 상영 정보가 전혀 없다.

 

'할인조건' 의 경우는 영화 정보도 모르고 상영 정보도 모른다.

 

하지만, '상영' 은 상영 정보와 영화 정보 그리고 가격에 대한 정보까지 모두 알고 있으므로 '예매' 객체를 생성하기 가장 합리적인 객체이다.

 

 

지금까지 배운 원칙을 유념해서 구현해보기

 

1️⃣ 영화를 '예매' 해라. '예매' 객체를 만들기 가장 합리적인 객체는 무엇일까?

creator 패턴으로 먼저 생각해보니, 상영 시간, 영화 정보, 가격 등을 다 알 수 있는 '상영' 객체가 이 책임을 맡는 것이 합당하다.

그러면, '상영' 클래스는 예매해라 라는 메세지를 처리할 수 있어야 하고 결과적으로 '예매' 객체를 생성해야한다.

public class Screening {
    public Reservation reserve(Customer customer, int audienceCount) {

    }
}

 

2️⃣ 책임을 부여했으므로, 그 책임을 수행하기 위한 데이터를 생각해도 된다.

상영 시간과 회차, 그리고 영화 데이터를 알고 있어야 예매 정보를 구성할 수 있을 것이다.

public class Screening {

    private Movie movie;
    private int sequence;
    private LocalDateTime whenScreened; 
    
    public Reservation reserve(Customer customer, int audienceCount) {

    }
}

 

3️⃣ 예매를 하기 위해서는, 영화 가격을 알아야한다.

영화 가격을 계산해라 라는 새로운 책임이 생겼다.

이 책임도 '상영' 이 맡는 것이 좋을까?

'상영' 이 '영화' 객체 안에 있는 가격을 다루기 보다는

'영화' 객체가 자신이 갖고 있는 데이터를 다루는 것이 객체의 자율성을 높여주는 판단이라고 생각한다.

혹시나, 상영 시간이라던지 상영 회차에 따라 할인 조건을 추가할 수도 있으므로 

'영화' 에게 가격을 계산하라고 요청할 때, '상영' 정보를 함께 전달하고 예매 인원수도 전달해준다.

public class Screening {

    private Movie movie;
    private int sequence;
    private LocalDateTime whenScreened;
    
    public Reservation reserve(Customer customer, int audienceCount) {
        return new Reservation(customer, this, calculateFee(audienceCount), audienceCount);
    }

    private Money calculateFee(int audienceCount) {
        return movie.calculateFee(this).times(audienceCount);
    }
}

 

public class Movie {
    public Money calculateMovieFee(Screening screening) {

    }
}

 

5️⃣ 이제 '영화'는 가격을 계산하라는 책임을 할당받았으므로 책임을 수행하기 위한 행동을 결정해야한다.

가격을 계산하라 라는 책임을 수행하기 위해 필요한 데이터를 생각해도 된다.

'영화'는 '할인조건'을 알고 있어야하고 기본 가격을 알고있어야한다.

그리고 해당 영화가 어떤 할인 정책을 따르고 있는지 알아야한다.

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(){
    	// 해당 영화의 할인 정책 (movieType)에 따라 적절한 할인가를 계산할 수 있도록 계산해서 반환하도록 하면 된다.
    }
    
    
}

 

 

6️⃣ 상영 정보를 바탕으로, 상영 정보가 할인 조건에 만족하는지 isSatisfiedBy 메서드를 통해 확인한다.

public class DiscountCondition {
    private DiscountConditionType type;
    private int sequence;
    private DayOfWeek dayOfWeek;
    private LocalTime startTime;
    private LocalTime endTime;

    public boolean isSatisfiedBy(Screening screening) {
        // 영화 할인 가능 여부가 회차면 screening 의 회차 확인
        // 할인 조건 가진 sequence와 비교
        
        // 영화 할인 가능 여부가 시간대면 screening의 시작 시간 확인
        // 할인 조건이 가진 startTime와 endTime과 비교
    }
    
}

 

🚨 여기서 설계를 잘한 것 같지만 살펴보면 문제점이 보인다.

 

만약, DiscountCondition의 할인 조건과 관련된 회차 기준이 바뀌면, isSatisfiedBy 코드는 변경되어야 한다.

 

그리고 할인 조건과 관련된 상영 시작과 끝나는 시간 기준이 바뀌어도 isSatisfiedBy 코드가 변경되어야 한다.

 

다시 말하면, isSatisfiedBy 코드는 변경이 일어나는 시점이 한 가지 이유가 아니라 여러가지 이유에 영향을 받는다.

 

따라서, 응집도가 낮다는 것을 알 수 있고 회차를 기준으로 할인 여부를 파악하는 클래스와 시간을 기준으로 할인 여부를 파악하는 클래스를 분리하는 것이 각 클래스의 응집도를 높일 수 있는 방법이다.

 

따라서, 할인 가능 여부를 파악하는 isSatisfiedBy 메서드는 인터페이스로서 정의하고

 

각 인터페이스를 구현하여 회차기준 할인 조건 클래스와 상영 시간 기준 할인 클래스를 정의하면 된다.

 

disCountCondition 클래스는 사실 기간을 비교하는 책임 1개와 회차를 비교하는 책임 1개를 각각 갖고 있던 셈이었다.

 

이를 쉽게 판단할 수 있는 방법은, 어떤 클래스의 핵심 책임을 구현하기 위한 행동이 자신이 갖고 있는 모든 인스턴스를 사용하는지로 판단할 수 있다.

 

discountCondition은 sequence도 갖고 startTime도 갖지만, isSatisfiedByPeriod() 메서드에서는 sequence는 사용되지 않고

 

isSatisfiedBySequence() 메서드에서는 startTime와 endTime이 사용되지 않는 것 처럼 말이다.

 

따라서, 위와 같은 구조로 개선시켜주면 하나의 클래스는 하나의 책임만 갖는 구조로 변경할 수 있다.

 

위와 같은 구조에서, 회차나 시간이 아닌 다른 할인 조건이 추가되어도 discountCondition 클래스를 구현하는 클래스를 추가함으로서 쉽게 추가할 수 있게된다.

 

Movie 클래스 역시, discountAmount와 discountPercent 과 같은 구체적인 할인 계산 프로세스와 관련된 변수를 갖고 있는데, 구체적인 방법은 할인가를 구해라 라는 역할로 추상화시켜 분리하고

 

구체적인 할인가 계산 방법은 책임으로서 클래스를 분리하면 더 유연한 구조로 개선할 수 있게된다.