[오브젝트 4장] - 설계 품질과 트레이드 오프

[오브젝트 4장] - 설계 품질과 트레이드 오프

 

 

이번 장은 영화 예매 시스템을 책임이 아닌 상태를 표현하는 데이터 중심의 설계를 살펴보고 객체지향적으로 설계한 구조와 어떤 차이점이 있는지 살펴보는 챕터입니다. 

 

 

 데이터 중심의 영화 예매 시스템

 

데이터 중심 설계는 '데이터가 무엇인가'를 묻는 것으로 시작한다. 먼저 Movie에 저장될 데이터를 결정하는 것으로 시작하자. 편의를 위해 접근자와 수정자는 롬북으로 대체한다.

 

@Getter
@Setter
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;

}

 

 

할인 정책의 종류를 결정하는 열거형 타입을 MovieType으로 설정한다. 

 

public enum MovieType {
    AMOUNT_DISCOUNT,   // 금액 할인 정책
    PERCENT_DISCOUNT,  // 비율 할인 정책
    NONE_DISCOUNT      // 미적용
}

 

 

데이터 중심 설계에서는 객체가 포함해야 하는 데이터를 집중한다. movieType이 금액 할인 정책이라면 discountAmount 값이 필요하고, 비율 할인 정책이라면 discountPercent가 필요하다. 

 

그리고 캡슐화를 위해 접근자와 수정자를 추가한다. 

 

다음으로 할인 조건을 구현하는 데 필요한 데이터는 무엇인가? 먼저 현재의 할인 조건의 종류를 저장할 데이터가 필요하다. 

 

public enum DiscountConditionType {
    SEQUENCE, // 순번조건
    PERIOD    // 기간조건
}

 

또한 기간조건과 순번 조건에서 사용되는 인스턴스 변수들을 추가해야 한다. 

 

@Getter
@Setter
public class DiscountCondition {
    private DiscountConditionType type;
    
    private int sequence;
    
    private DayOfWeek dayOfWeek;
    private LocalTime startTime;
    private LocalTime endTime;
}

 

 

마찬가지로 Screening, Reservation, Customer 클래스를 추가한다. 

 

// Screening.java
@Getter
@Setter
public class Screening {
    private Movie movie;
    private int sequence;
    private LocalDateTime whenScreened;
}

// Reservation.java
@Getter
@Setter
public class Reservation {
    private Customer customer;
    private Screening screening;
    private Money fee;
    private int audienceCount; 
}

// Customer.java
@Getter
@Setter
public class Customer {
    private String name;
    private String id;
}

 

 

 

 

 

 영화예매 시뮬레이션

 

ReservationAgency는 데이터 클래스들을 조합해서 영화 예매 절차를 구현하는 클래스다.

 

public class ReservationAgency {
    
    public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
        Movie movie = screening.getMovie();
        
        boolean discountable = false;
        for (DiscountCondition condition: movie.getDiscountConditions()) {
            if (condition.getType() == DiscountConditionType.PERIOD) {
                discountable = screening.getWhenScreened().getDayOfWeek().equals(condition.getDayOfWeek()) && 
                        condition.getStartTime().compareTo(screening.getWhenScreened().toLocalTime()) <= 0 && 
                        condition.getEndTime().compareTo(screening.getWhenScreened().toLocalTime()) >= 0;
            } else {
                discountable = condition.getSequence() == screening.getSequence();
            }
            
            if (discountable) {
                break;
            }
        }
        
        Money fee;
        if (discountable) {
            Money discountAmount = Money.ZERO;
            switch (movie.getMovieType()) {
                case AMOUNT_DISCOUNT:
                    discountAmount = movie.getDiscountAmount();
                    break;
                case PERCENT_DISCOUNT:
                    discountAmount = movie.getFee().times(movie.getDiscountPercent());
                    break;
                case NONE_DISCOUNT:
                    discountAmount = Money.ZERO;
                    break;
            }
            
            fee = movie.getFee().minus(discountAmount).times(audienceCount);
        } else {
            fee = movie.getFee().times(audienceCount);
        }
        
        return new Reservation(customer, screening, fee, audienceCount);
    }
}

 

 

 

 

 설계 트레이드 오프

 

'캡슐화', '응집도', '결합도'를 기준으로 책임 주도 설계와 데이터 중심 설계를 비교해보자. 

 

 

 

 

 캡슐화

 

상태와 행동을 하나의 객체 안에 모으는 이유는 내부 구현을 외부로부터 감춰서 변경 파급효과를 줄이기 위해서다. 변경 가능성이 높은 부분을 '구현'이라고 부르고 상대적으로 안정적인 부분을 '인터페이스'라고 부른다. 

 

이를 위한 장치로 '캡슐화'를 사용하는 것이다. 객체지향 설계의 가장 중요한 원리는 불안정한 구현 세부사항을 안정적인 인터페이스 뒤로 캡슐화하는 것이다. 

 

'유지보수성이 목표다. 여기서 유지보수성이란 두려움 없이, 주저함 없이, 저항감 없이 코드를 변경할 수 있는 능력을 말한다. 가장 중요한 동료는 캡슐화다. 캡슐화는 어떤 것을 숨기는 것을 의미하는데 이를 통해 뜻밖의 피해가 발생할 수 있는 가능성을 사전에 방지할 수 있다. 응집도, 결합도, 중복 역시 훌륭한 코드를 규정하는 데 핵심적인 품질인 것이 사실이지만 캡슐화는 우리를 좋은 코드로 안내하기 때문에 가장 중요한 제1원리다.'

 

 

 

 

 응집도와 결합도

 

응집도는 모듈에 포함된 내부 요소들이 연관돼 있는 정도를 나타낸다. 결합도는 의존성의 정도를 나타내며 다른 모듈에 대해 얼마나 많은 지식을 갖고 있는지를 나타내는 척도다. 

 

변경의 관점에서 응집도란 '변경이 발생할 때 모듈 내부에서 발생하는 변경의 정도'로 측정할 수 있다. 간단히 말해 하나의 변경으로 모듈 전체가 변경된다면 응집도가 낮은 것이다. 응집도가 높은 설계에서는 하나의 요구사항 변경을 반영하기 위해 오직 하나의 모듈만 수정하면 된다. 

 

결합도 역시 변경의 관점에서 '한 모듈이 변경되기 위해서 다른 모듈의 변경을 요구하는 정도'로 측정할 수 있다. 어떤 모듈을 변경했을 때 다른 모듈들을 수정해야 한다면 이는 결합도가 높은 것이다.

보통 내부 구현을 변경했을 때 다른 모듈에 영향이 끼치면 결합도가 높은 것이고 퍼블릭 인터페이스를 변경했을 때만 다른 모듈에 영향이 끼칠 때 결합도가 낮다고 표한한다. 

 

 

 

 

 데이터 중심의 영화 예매 시스템의 문제점

 

데이터 중심의 설계는 캡슐화를 위반하고 객체의 내부 구현을 인터페이스에 드러나게 한다. 

 

이 때문에 다음 세 가지 문제점들이 존재한다.

- 캡슐화 위반

- 높은 결합도

- 낮은 응집도

 

 

롬북을 통해 접근자와 수정자를 사용해서 변수에 접근하는 것은 캡슐화의 원칙을 지키는 것처럼 보이지만 그렇지 않다. getFee와 setFee는 퍼블릭 인터페이스에 노골적으로 fee라는 인스턴스 변수가 있는 것을 드러내고 있다. 그리고 이렇게 변수를 갖고온다면 이 변수를 사용하는 클라이언트는 fee라는 이름의 변수가 변경되었을 때 전부 영향을 받게 된다. 이는 높은 결합도로 생기는 일이다.

 

엘빈 홀럽은 이처럼 접근자와 수정자에 과도하게 의존하는 설계 방식을 '추측에 의한 설계 전략'이라고 부른다.이 전략은 객체의 협력을 고려하지 않고 다양한 상황에서 사용될 것이라는 가정하에 설계를 한다. 결과적으로 내부 구현이 퍼블릭 인터페이스에 그대로 드러나게 되면서 캡슐화의 원칙을 위반하는 변경에 취약한 설계를 얻게 된다. 

 

서로 다른 이유로 변경되는 코드가 하나의 모듈 안에 공존할 때 모듈의 응집도가 낮다고 말한다. 따라서 각 모듈의 응집도를 살펴보기 위해서는 코드를 수정하는 이유가 무엇인지 살펴봐야 한다. 

 

ReservationAgency는 다음과 같은 수정사항이 발생하는 경우에 코드를 수정해야 할 것이다.

- 할인 정책이 추가되는 경우

- 할인 정책별로 할인 요금을 계산하는 방법이 변경될 경우

- 할인 조건이 추가되는 경우

- 할인 조건별로 할인 여부를 판단하는 방법이 변경될 경우

- 예매 요금을 계산하는 방법이 변경될 경우

 

할인 정책을 선택하는 코드와 할인 조건을 판단하는 코드가 함께 존재하기에 새로운 할인 정책을 추가하는 작업이 할인 조건에도 영향을 미칠 수 있다. 

이처럼 어떤 요구사항 변경을 수용하기 위해 하나 이상의 클래스를 수정해야 하는 것은 설계의 응집도가 낮다는 것이다. 

 

 

 

 

 스스로 자신의 데이터를 책임지는 객체

 

 

응집도를 높이기 위해 객체 내부에 저장되는 데이터보다 객체가 협력에 참여하면서 수행할 책임을 정의하는 오퍼레이션에 초점을 맞춰야 한다. 따라서 객체를 설계할 때 "이 객체가 어떤 데이터를 포함해야 하는가?"라는 질문은 다음의 두 개로 분리해야 한다.

 

- 이 객체가 어떤 데이터를 포함해야 하는가?

- 이 객체가 데이터에 대해 수행해야 하는 오퍼레이션은 무엇인가? 

 

두 질문을 조합하면 객체의 내부 상태를 저장하는 방식과 저장된 상태에 대해 호출할 수 있는 오퍼레이션의 집합을 얻을 수 있다. 

 

먼저 DiscountCondition 타입에 있는 데이터에 대해 수행할 수 있는 오퍼레이션이 무엇인지 알아보자. 두 가지 할인 조건을 판단할 수 있도록 isDiscountable 메서드를 만들어보자.

 

@Getter
@Setter
public class DiscountCondition {
    private DiscountConditionType type;

    private int sequence;

    private DayOfWeek dayOfWeek;
    private LocalTime startTime;
    private LocalTime endTime;
    
    public boolean isDiscountable(DayOfWeek dayOfWeek, LocalTime time) {
        if (type != DiscountConditionType.PERIOD) {
            throw new IllegalArgumentException();
        }
        
        return this.dayOfWeek.equals(dayOfWeek) && this.startTime.compareTo(time) <= 0 && this.endTime.compareTo(time) >= 0;
    }
    
    public boolean isDiscountable(int sequence) {
        if (type != DiscountConditionType.SEQUENCE) {
            throw  new IllegalArgumentException();
        }
        
        return this.sequence == sequence;
    }
}

 

 

이제 Movie를 변경해보자. Movie의 데이터를 처리하기 위한 오퍼레이션은 무엇인가? Movie가 포함하는 데이터를 살펴보면 영화 요금을 계산하는 오퍼레이션과 할인 여부를 판단하는 오퍼레이션이 필요할 것 같다. 

 

@Getter
@Setter
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 calculateAmountDiscountedFee() {
        if (movieType != MovieType.AMOUNT_DISCOUNT) {
            throw new IllegalArgumentException();
        }
        
        return fee.minus(discountAmount);
    }

    public Money calculatePercentDiscountedFee() {
        if (movieType != MovieType.PERCENT_DISCOUNT) {
            throw new IllegalArgumentException();
        }

        return fee.times(discountPercent);
    }
    
    public Money calculateNoneDiscountFee() {
        if (movieType != MovieType.NONE_DISCOUNT) {
            throw new IllegalArgumentException();
        }
        
        return Money.ZERO;
    }
    
    public boolean isDiscountable(LocalDateTime whenScreened, int sequence) {
        for(DiscountCondition condition : discountConditions) {
            if (condition.getType() == DiscountConditionType.PERIOD) {
                if (condition.isDiscountable(whenScreened.getDayOfWeek(), whenScreened.toLocalTime())) {
                    return true;
                }
            } else {
                if (condition.isDiscountable(sequence)) {
                    return true;
                }
            }
        }
        
        return false;
    }

}

 

 

Screening 역시 데이터를 처리하기 위한 오퍼레이션을 구현하여 자율성을 높이자.

 

@Getter
@Setter
public class Screening {
    private Movie movie;
    private int sequence;
    private LocalDateTime whenScreened;

    public Money calculateFee(int audienceCount) {
        switch (movie.getMovieType()) {
            case AMOUNT_DISCOUNT:
                if (movie.isDiscountable(whenScreened, sequence)) {
                    return movie.calculateAmountDiscountedFee().times(audienceCount);
                }
                break;
            case PERCENT_DISCOUNT:
                if (movie.isDiscountable(whenScreened, sequence)) {
                    return movie.calculatePercentDiscountedFee().times(audienceCount);
                }
                break;
            case NONE_DISCOUNT:
                return movie.calculateNoneDiscountFee().times(audienceCount);
        }
        
        return movie.calculateNoneDiscountFee().times(audienceCount);
    }
}

 

 

이제 이 자율적인 객체들을 사용해서 영화를 예매해보자.

 

public class ReservationAgency {
    public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
        Money fee = screening.calculateFee(audienceCount);
        return new Reservation(customer, screening, fee, audienceCount);
    }
}

 

결합도 측면에서 ReservationAgency에 몰려있던 의존성이 충분히 개선되었다. 

 

 

 

 하지만 여전히 부족하다.

 

캡슐화 관점에서 두 번째 설계가 첫 번째보다 향상된 건 사실이지만 여전히 캡슐화를 위반하는 부분이 존재한다.

 

Screening의 isDiscountable(DayofWeek dayOfWeek, LocalTime time) 메서드는 내부에 dayOfWeek, time 변수를 포함하고 있음을 노출하고 있다.  Movie역시 내부 구현을 인터페이스에 노출시키고 있다. calculateAmountDiscountedFee는 이름으로 내부 구현을 노출시키고 있다. 해당 메서드 이름을 변경한다면? 새로운 할인정책을 추가한다면? 이를 사용하는 클라이언트 코드 역시 수정해야 한다.

 

내부 속성을 캡슐화했더라도 내부 구현의 변경으로 인해 외부의 객체가 영향을 받는다면 캡슐화를 위반한 것이다. 설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화해야 한다. 위 두 개의 메서드 같은 경우에는 이를 인터페이스로 한 단계 추상화해서 변수와 메서드의 이름을 숨기는 것이 클라이언트 코드 변경의 파급효과를 줄일 수 있을 것이다. 

 

 

 

 

 데이터 중심 설계의 문제점

 

데이터 중심 설계가 변경에 취약한 이유는 두 가지다.

- 데이터 중심의 설계는 본질적으로 너무 이른 시기에 데이터에 관해 결정하도록 강요한다.

- 데이터 중심의 설계에서는 협력이라는 문맥을 고려하지 않고 객체를 고립시킨 채 오퍼레이션을 결정한다. 

 

데이터 중심 설계의 시작은 "이 객체가 포함해야 하는 데이터가 무엇인가?"이다. 시작부터 내부 구현에 초점을 맞춰 생각하는 것이다. 

데이터 중심 설계 방식에 익숙한 개발자들은 일반적으로 데이터와 기능을 분리하는 절차적 프로그래밍 방식을 따른다. 객체는 데이터를 담고 있는 집합체일 뿐이고 접근자와 수정자를 과도하게 추가하여 사용한다. 이로인해 캡슐화는 무너진다.

 

그리고 두 번째 설계처럼 데이터를 처리하는 오퍼레이션을 객체 내부에 만들게 되더라도 데이터를 중심으로 오퍼레이션을 정의하는 것이기 때문에 내부 구현이 인터페이스에 드러나게 된다. 이 또한 캡슐화를 위반하게 되고 변경에 취약해진다. 

 

올바른 객체지향 설계의 무게 중심은 항상 객체의 내부가 아닌 외부에 있어야 한다. 하지만 데이터 중심설계는 내부로 향한다. 객체의 인터페이스가 내부 구현에 종속돼 있었기 때문에 내부 구현이 변경되었을 때 협력하는 객체 모두가 영향을 받을 수 밖에 없던 것이다.