[오브젝트] #5. 책임 할당하기

bien·2024년 10월 4일

오브젝트 책

오브젝트

목록 보기

5/13

데이터가 아닌 책임에 초점을 맞춰야 한다.

책임 할당 과정; 일종의 트레이드 오프 활동
- 동일한 문제를 해결할 수 있는 다양한 책임 할당 방법이 존재한다.
- 어떤 방법이 최선인지는 상황과 문맥에 따라 달라진다.
- 올바른 책임 할당을 위해서는, 다양한 관점에서 설계를 평가할 수 있어야 한다.

01. 책임 주도 설계를 향해

책임 주도 설계의 2가지 원칙
1. 데이터보다 행동을 먼저 결정해라.
2. 협력이라는 문맥 안에서 책임을 결정해라.
설계 진행 동안, 객체가 아니라 협력에 초점을 맞춰야 한다.

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

객체의 핵심; 외부에 제공하는 행동
- 클라이언트에게 객체의 행동 => 객체의 책임
- 객체는 자신의 행동을 통해 협력에서의 존재가치를 증명한다.
객체의 데이터; 책임 수행에 필요한 재료
설계의 결정사항 및 순서
- 데이터 중심 설계
  1. 이 객체가 포함해야 하는 데이터가 무엇인가?
  2. 데이터를 처리하는데 필요한 오퍼레이션이 무엇인가?
- 책임 중심 설계
  1. 이 객체가 수행해야하는 책임이 무엇인가?
  2. 이 책임을 수행하는 데 필요한 데이터는 무엇인가?

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

🧐 객체의 책임은 어떻게 할당해야 할까?
이 방법을 객체 책임의 평가 기준으로부터 확인할 수 있다.

객체에게 주어진 책임의 품질; 협력에 적합한 정도로 결정
- 책임은 객체가 아니라, 객체가 참여하는 협력에 적합해야 한다.
- 이 사실은 객체의 책임을 어떻게 식별해야 하는가를 알려준다.
  - 협력의 시작 주체는 메시지 전송자이므로, 협력에 적합한 책임이란 메시지 전송자에게 적합한 협력을 의미한다.
  - 즉, 클라이언트의 의도에 적합한 책임을 할당해야 한다.

협력에 적합한 책임; 메시지를 결정한 후에 객체를 선택해야 한다.
- 메시지 기반 설계; 메시지를 전송해야 하는데 누구에게 전송하지?
- 메시지; 클라이언트의 의도를 표현
  - 클라이언트는 임의의 객체가 자신의 메시지를 수신할 것을 믿고, 자신의 의도를 표현한 메시지를 전송한다.
    - 메시지 수신자를 깔끔하게 캡슐화할 수 있다.
책임 중심 설계; 협력이라는 문맥 안에서 객체가 수행할 책임에 초점

책임 주도 설계

책임 주도 설계의 흐름 (3장)

시스템이 사용자에게 제공해야 하는 기능인 시스템 책임을 파악한다.

시스템 책임을 더 작은 책임으로 분할한다.

분할된 책임을 수행할 수 있는 적절한 객체 또는 역할을 찾아 책임을 할당한다.

객체가 책임을 수행하는 도중 다른 객체의 도움이 필요한 경우 이를 책임질 적절한 객체 또는 역할을 찾는다.

해당 객체 또는 역할에게 책임을 할당함으로써 두 객체가 협력하게 한다.

책임 주도 설계의 핵심
- 책임을 결정한 후에 책임을 수행할 객체를 결정하는 것.
- 협력에 참여하는 객체들의 책임이 어느 정도 정리될 때까지는 객체의 내부 상태에 대해 관심을 가지지 않는 것.

02. 책임 할당을 위한 GRASP 패턴

GRASP 패턴
- General Responsibility Assignment Software Pattern
  - (일반적인 책임 할당을 위한 소프트웨어 패턴) 의 약자
- 객체에게 책임을 할당할 때 지침으로 삼을 수 있는 원칙들의 집합을 패턴 형식으로 정리
- 크레이그 라만(Craing Larman)이 패턴 형식으로 제안

도메인 개념에서 출발하기

설계 시작 전, 도메인에 대한 개략적인 모습을 그려보는 것이 유용하다.
- 책임 할당 시 가장 고민해야 하는 유력한 후보는 바로 도메인 개념이다.

1. 하나의 영화는 여러번 상영될 수 있으며, 하나의 상영은 여러변 예약될 수 있다는 것을 보여준다.
2. 영화는 다수의 할인 조건을 가질 수 있으며, 
	할인 조건에는 순번 조건과 기간 조건이 존재한다는 사실이 표현되어 있다.
3. 할인 조건은 순번 조건과 기간 조건으로 분류되고 영화는 금액이나 비율에 따라 할인될 수 있지만, 
	동시에 두 가지 할인 조건을 적용할 수 없다는 사실이 표현되어 있다.

설계 시작 단계에서는 개념들의 의미와 관계가 정확하거나 완벽할 필요 없다.
- 단순한 출발점으로, 책임을 할당받을 객체들의 종류와 관계에 대한 유용한 정보를 제공할 수 있으면 충분하다.
- 도메인 개념 정리에 많은 시간을 들이지 말고, 빠르게 설계와 구현을 진행해라.

올바른 모델이란 존재하지 않는다.

2장에서 설정한 도메인에서는, 할인 정책이라는 개념이 독립적인 개념으로 분리되어 있었지만, 현재 도메인에서는 영화의 종류로 표현되어 있다.

어느 쪽이 올바른 도메인인가?

두 도메인 모두 올바른 구현을 이끌어낼 수 있다면 정답은 '둘 다'이다.

올바른 도메인은 존재하지 않는다.

필요한 것은 도메인을 그대로 투영한 모델이 아니라, 구현에 도움이 되는 모델. 다시 말해 실용적이면서도 유용한 모델이다.

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

1단계; App이 제공해야 하는 기능을, 애플리케이션의 책임으로 간주

책임을 App에 전송된 메시지로 간주하고, 이 메시지를 책임질 첫 번째 객체를 선택하는 것으로 설계를 시작한다.

질문1; 메시지를 전송할 객체는 무엇을 원하는가?
- 영화를 예매하는 것; 예매하라
질문2; 메시지를 수신할 적합한 객체는 누구인가?; Screening
- 책임 할당의 첫번째 원칙; 책임을 수행할 정보를 알고있는 객체에게 책임을 할당하는 것.
  - 이를 정보 전문가 패턴이라고 한다.
- 정보를 알고 있다는 것은 반드시 해당 정보를 '저장'하고 있어야 함을 의미하지는 않는다.
  1. 필요한 정보를 계산해서 제공하거나
  2. 정보를 제공할 수 있는 다른 객체를 알고있는 경우도 포함한다.

정보 전문가 패턴(INFORMATION EXPERT)

책임을 수행하는 데 필요한 정보를 가지고 있는 객체에게 책임을 할당하는 패턴.

객체가 자신이 소유하고 있는 정보와 관련된 작업을 수행한다는 일반적인 직관을 표현

정보를 알고 있는 객체만이 책임을 어떻게 수행할지 결정할 수 있다.

정보와 행동을 최대한 가까운 곳에 위치시켜 캡슐화를 유지할 수 있다.

필요한 정보를 가진 객체들로 책임이 분산되므로, 더 응집력있고 이해하기 쉬워진다.

따라서 높은 응집도가 가능하다.

결합도가 낮아져, 간결하고 유지보수 하기 쉬운 시스템을 구축할 수 있다.

질문3; 외부의 인터페이스가 아닌, 내부의 절차와 구현을 고민해본다.
- 예매하라라는 메시지를 수신했을 때, Screening이 수행해야 하는 작업의 흐름을 생각해본다.
- 이 때, 스스로 책임질 수 없는 작업이 있다면, 외부로 전송해야 할 도움(=새로운 메시지)을 고려해 새로운 객체에게 위임할 책임을 설계한다.

예약하라라는 메시지를 완료하기 위해, 예매 금액을 계산하는 작업이 필요하다.
예매 금액은 영화 한 편의 가격에 예매 인원수를 곱한 값으로 구할 수 있다. Screening은 영화 한편의 가격을 알지 못하므로, 필요한 정보를 알고 있는 외부 객체에게 도움을 요청해 가격을 얻어야 한다.

질문1; 메시지를 전송할 Screening은 무엇을 원하는가?
- 영화의 가격을 아는 것; 가격을 계산하라
질문2; 메시지를 수신할 적합한 객체는 누구인가?; Movie
- INFORMATION EXPERT(정보 전문가)패턴에 따라, 메시지 수신에 가장 적절한 객체는 Movie이다.
질문3; 내부의 절차와 구현을 고민해본다.
- 요금을 계산하기 위해서는 영화가 할인 가능한지 판단한 후, 할인 정책에 따라 할인 요금을 제외한 금액을 계산해야 한다.
- 이 중, 할인 조건에 따라 영화가 할인 가능한지 판단하는 작업은 Movie가 수행할 수 없다.
  - 따라서, 외부에 도움을 요청한다.
할인 여부 판단에 가장 적합한 객체는 할인 조건(DiscountCondition)이다.
- DiscountCondition은 할인 여부 판단에 필요한 모든 정보를 알고 있으므로, 외부 도움 없이도 스스로 할인 여부를 판단할 수 있다.
  - 따라서, DiscountCondition은 외부에 메시지를 전송하지 않는다.

📌 결론

INFORMATION EXPERT (정보 전문가) 패턴
- 객체에게 책임 할당 시, 가장 기본이 되는 책임 할당 원칙이다.
- 객체란 상태와 행동을 함께 가지는 단위라는 객체지향의 가장 기본적인 원리를 책임 할당의 관점에서 표현한다.
- 이 패턴을 따르는 것 만으로도 자율성이 높은 객체들로 구성된 협력 공동체를 구성할 가능성이 높아진다.

높은 응집도와 낮은 결합도

수많은 설계 선택지 중, 무엇을 기준으로 선택해야 할까? 높은 응집도와 낮은 결합도를가지는 설계를 선택해라.

설계는 트레이드 오프다.
동일한 기능을 구현할 수 있는 무수히 많은 설계 중, 하나를 선택해야 하는 경우가 빈번하다. 이 경우에는 올바른 책임 할당을 위해 INFORMATION EXPERT(정보 전문가) 패턴 이외에도 다른 책임 할당 패턴을 함께 고려할 필요가 있다.

위의 그림과 같이, Moive가 DiscountCondition에게 할인금액을 요구하지 않고, Screening이 직접 DiscountCondition에게 할인 금액을 요구하도록 설계할 수도 있다.
기능 적인 측면에서는 두 설계에서 차이가 없는 상황에서, 왜 이 설계 대신 Movie가 DisocuntCondition과 협력하는 방법을 선택한 것일까?

그 이유는 응집도와 결합도다.
높은 응집도와 낮은 결합도는 책임 할당 시 항상 고려되어야 하는 기본 원리이다. 책임 할당의 다양한 설계 선택지 중, 응집도와 결합도 측면에서 더 나은 대안을 선택하는 것이 좋다.

GRASP에서는 이를 LOW COUPLING(낮은 결합도) 패턴과 HIGH COHESIONG(높은 응집도) 패턴이라고 부른다.

LOW COUPLING (낮은 결합도)

LOW COUPLING 패턴

설계의 전체적인 결합도가 낮도록 설계해라.

의존성을 낮추고, 변화의 영향을 줄이며, 재사용성을 증가시킨다.

🤔 DiscountCondition은 Movie와 협력하는 것이 좋을까, 아니면 Screening과 협력하는 것이 좋을까?
- 앞서 살펴본 도메인 구조에서 Movie와 DiscountCondition은 이미 결합되어 있어, 둘 간의 협력은 설계 전체적으로 결합도를 추가하지 않는다.
- 하지만 Screening이 DiscountCondition과 협력하는 경우, 새로운 결합도가 추가된다.
- 따라서, LOW COUPLING(낮은 결합도) 측면에서는 Movie와 협력하는 것이 더 나은 설계 대안이다.

HIGH COHESION (높은 응집도)

HIGH COHESION 패턴

높은 응집도를 유지할 수 있게 책임을 할당해라.

복잡성을 관리할 수 있는 수준으로 유지할 수 있다.

Screnning 의 경우

Screening의 가장 큰 책임은 예매를 생성하는 것이다.
- 만약 Screening이 DiscountCondition과 협력해야 한다면, Screening은 영화 요금 계산과 관련된 책임 일부를 떠안게 된다.
- 이 경우 Screening은 아래 정보를 모두 알고 있어야 한다.
  1. DiscountCondition이 할인 여부를 판단할 수 있다는 사실.
  2. Movie가 할인 여부를 필요로 한다는 사실
만약 예매 요금 계산 방식이 변경될 경우, Screening도 함께 변경되어야 한다.
- 결과적으로 Screening과 DiscountCondition이 협력하면, Screening은 서로 다른 이유로 변경되어야 하는 책임을 짊어지게 되므로, 응집도가 낮아질 수 밖에 없다.

Movie 의 경우

Movie의 주된 책임은 영화 요금을 계산하는 것이다.
- 따라서 Movie와 DiscountCondition의 협력은 전체 설계의 응집도에 아무런 해도 끼치지 않는다.

📌 결론

낮은 결합도(LOW COUPLING)과 높은 응집도(HIGH COHESION)은 설계에서 책임과 협력의 품질 결정에 중요한 평가 기준이다.
- 여러 설계 대안 중 최선을 선정하기 위해 이 평가 기준들을 활용해라!

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

영화 예매 협력의 최종 결과물; Reservation 인스턴스
- 이는 협력에 참여하는 어떤 객체에게는 Reservation 인스턴스 생성의 책임을 할당해야 함을 의미한다.
GRASP의 CREATOR(창조자) 패턴은 책임 할당 패턴에서 객체를 생성할 책임을 어떤 객체에게 할당할지에 대한 지침을 제공한다.

CREATOR 패턴

아래 조건을 최대한 많이 만족하는 B에게 객체 A의 생성 책임을 할당해라.
- B가 A 객체를 포함하거나 참조한다.
- B가 A 객체를 기록한다.
- B가 A 객체를 긴밀하게 사용한다.
- B가 A 객체를 초기화하는데 필요한 데이터를 가지고 있다.
  - 이 경우 B는 A에 대한 정보 전문가다.
CREATOR 패턴의 의도는 어떤 방식으로든 생성되는 객체와 연결되거나 관련될 필요가 있는 객체에 해당 객체를 생성할 책임을 맡기는 것이다.
- 생성될 객체에 대해 잘 알고 있어야 하거나, 그 객체를 사용해야 하는 객체는 어떤 방식으로든 생성될 객체와 결합된다.
- 이미 결합돼 있는 객체에게 생성 책임을 할당하는 것은 전체 결합도에 영향을 미치지 않는다.
  - CREATOR 패턴은 이미 존재하는 객체 사이의 관계를 이용하므로, 낮은 결합도를 유지할 수 있게 한다.

03. 구현을 통한 검증

Screening

책임; 예매에 대한 정보 전문가 & Reservation의 창조자
- 영화 예매의 책임
  - 결과로 Reservation 인스턴스를 생성.

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

책임에 요구되는 인스턴스 변수
- 상영시간(whenScreened)
- 상영순번(sequence)
- 가격 계산 메시지 전송을 위한 참조 영화(movie)

    private Movie movie;
    private int sequence;
    private LocalDateTime whenScreened;

협력을 위한 메시지 정의
- Movie에 전송하는 메서드 시그니처가 calcualteMovieFee(Screening screening)임에 주목하자.
  - 메시지 수신자인 Movie가 아니라, 송신자인 Screening의 의도를 표현했다.
  - 여기서 중요한 점은 Screening이 Movie의 구현을 고려하지 않고 필요한 메시지를 결정함으로써, Movie의 내부 구현을 깔끔하게 캡슐화했다는 점이다.

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

결과물 💻 Screening.java

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);
    }

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

Movie

협력을 위한 기능 수행
- 영화의 금액 계산 (할인 정책 포함)

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

책임 수행에 요구되는 인스턴스 변수 선언

    private String title; 
    private Duration runningTime;
    private Money fee;
    private List<DiscountCondition> discountConditions;

    private MovieType movieType;
    private Money discountAmount;
    private Doublie discountPercent;

할인 정책 종류 열거형

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

책임 기능 수행

    public Money calculateMovieFee(Screening screening) {
        if(isDiscountable(screening)) {
            return fee.minus(calculateDiscountAmount());
        }

        return fee;
    }

    public boolean isDiscountable(Screening screening) {
        return discountConditions.stream()
                .anyMatch(condition -> condition.isSatisfiedBy(screening));
    }

실제 할인 요금을 계산; calculateDiscountAmoun

    private Money calculateDiscountAmount() {
        switch(movieType) {
            case AMOUNT_DISCOUNT:
                return calculateAmountDiscountAmount();
            case PERCENT_DISCOUNT:
                return calculatePercentDiscountAmount();
            case NONE_DISCOUNT:
                return calculateNoneDiscountAmount();
        }

        throw new IllegalStateException();
    }

    public Money calculateAmountDiscountAmount() {
        return discountAmount;
    }

    public Money calculatePercentDiscountAmount() {
        return fee.minus(discountAmount);
    }

    public Money calculateNoneDiscountAmount() {
        return Money.ZERO;
    }

결과물 💻 Movie.java


public class Movie {
    private String title;
    private Duration runningTime;
    private Money fee;
    private List<DiscountCondition> discountConditions;

    private MovieType movieType;
    private Money discountAmount;
    private Doublie discountPercent;

    public Money calculateMovieFee(Screening screening) {
        if(isDiscountable(screening)) {
            return fee.minus(calculateDiscountAmount());
        }

        return fee;
    }

    public boolean isDiscountable(Screening screening) {
        return discountConditions.stream()
                .anyMatch(condition -> condition.isSatisfiedBy(screening));
    }

    private Money calculateDiscountAmount() {
        switch(movieType) {
            case AMOUNT_DISCOUNT:
                return calculateAmountDiscountAmount();
            case PERCENT_DISCOUNT:
                return calculatePercentDiscountAmount();
            case NONE_DISCOUNT:
                return calculateNoneDiscountAmount();
        }

        throw new IllegalStateException();
    }

    public Money calculateAmountDiscountAmount() {
        return discountAmount;
    }

    public Money calculatePercentDiscountAmount() {
        return fee.minus(discountAmount);
    }

    public Money calculateNoneDiscountAmount() {
        return Money.ZERO;
    }

}

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

DiscountCondition

책임
- 할인 여부를 판단하라

public class DiscountCondition {
	public boolean isSatisfiedBy(Screening screening) {}
}

힐인 조건 종류 열거형

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

결과물 💻 DiscountCondition.java

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 isSatisfiedSequence(screening);
    }

    private boolean isSatisfiedByPeriod(Screening screening) {
        return dayOfWeek.equals(screening.getWhenScreened().getDayOfWeek()) &&
                startTime.compareTo(screening.getWhenScreened().toLocalTime()) <= 0 &&
                endTime.isAfter(screening.getWhenScreened().toLocalTime()) >= 0;
    }

    private boolean isSatisfiedSequence(Screening screening) {
        return sequence == screening.getSequence();
    }

}

코드추가 💻 Screening.java

public LocalDateTime getWhenScreened() {
	return whenScreened;
}

public int getSequence() {
	return sequence;
}

🛠️ DiscountCondition 개선하기

DiscountCondition
- 변경에 취약한 클래스; 수정해야 하는 이유를 하나 이상 가지는 클래스

- 변경이유 1; 새로운 할인 조건 추가
   - `isSatisfiedBy`의 `if ~ else`구문 수정 필요
   - `DiscountCondition`에 새로운 할인조건에 필요한 조건 속성을 추가.
- 변경이유2; 순번 조건을 판단하는 로직 변경
   - `isSatisfiedBySequence` 내부 구현 수정
   - 순번 조건에 요구되는 데이터인 `sequence` 속성 변경.
- 변경이유3; 기간 조건을 판단하는 로직이 변경되는 경우
   - `isSatisfiedBySequence` 내부 구현 수정
   - 순번 조건을 판단하는데 필요한 데이터 변경 필요.

낮은 응집도
- 하나 이상의 변경 이유를 가지는 클래스
  - 서로 연관성이 없는 기능이나 데이터가 하나의 클래스 안에 뭉쳐있음을 의미
설계 계선 작업 시, 변경의 이유가 하나 이상인 클래스를 찾는 것으로 시작.
- 변경 이유가 하나 이상인 클래스는, 몇 가지 뚜렷한 패턴을 보인다.

문제점; 변경 이유가 하나 이상인 클래스

인스턴스 변수 초기화 시점 파악
- 응집도가 높은 클래스는 인스턴스 생성 시 모든 속성을 함께 초기화한다.
  - 클래스의 속성이 서로 다른 시점에 혹은 일부만 초기화되는 경우, 함께 초기화되는 속성을 기준으로 코드를 분리해야 한다.
메서드들이 인스턴스 변수를 사용하는 방식 파악
- 모든 메서드가 객체의 모든 속성을 사용한다면, 클래스의 응집도가 높은 것이다.
- cf. 메서드들이 사용하는 속성에 따라 그룹이 나뉜다면, 응집도가 낮은 것이다.
  - 속성 그룹과 해당 그룹에 접근하는 메서드 그룹을 기준으로 코드를 분리해야 한다.

📌 클래스의 응집도 파악

다음은 낮은 응집도를 가지는 클래스의 징후들이다.
대부분 아래 세 가지 문제를 동시에 가진다.

클래스가 하나 이상의 이유로 변경돼야 하는 경우

변경 이유를 기준으로 클래스 분리

클래스의 인스턴스 초기화 시점에, 서로 다른 속성 혹은 일부의 속성을 초기화

초기화되는 속성의 그룹을 기준으로 클래스 분리

메서드 그룹이 속성 그룹을 사용하는지 여부로 그룹화

그룹을 기준으로 클래스 분리

해결법1; 타입 분리하기

클래스 분리를 통해 앞서 언급된 문제점들을 해결할 수 있다.
- 각 클래스에서 로컬 변수를 함께 초기화한다.
- 모든 메서드는 동일한 인스턴스 변수 그룹을 사용한다.
  - 결과적으로 클래스의 응집도를 향상시켰다.

PeriodCondition.java

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.isAfter(screening.getWhenScreened().toLocalTime()) >= 0;
    }
}

SequenceCondition.java

public class SequenceCondition {
    private int sequence;

    public SequenceCondition(int sequence) {
        this.sequence = sequence;
    }

    public boolean isSatisfiedBy(Screening screening) {
        return sequence == screening.getSequence();
    }
}

그러나, Movie와 협력하는 클래스가 DiscountCondition하나에서 PeriodCondition, SequenceCondition 2개로 늘어났다.
- 서로 다른 클래스의 인스턴스를 모두 가지고, 따로 협력해야 한다.

이 문제를 해결하기 위해, Movie안에서 두 클래스의 목록을 따로 유지할 수 있다.
- 이 설계 방식은 새로운 문제를 야기한다.
  1. Movie가 PeriodCondition과 SequenceCondition 양쪽 모두에 결합되어야 한다.
    - 전체적인 결합도가 상승했다.
  2. 수정 후 새로운 할인 조건 추가가 더 어려워졌다.
    - 새로운 List추가, isDiscountable 메서드에 추가, 할인조건판단 로직 추가가 필요해짐.

Movie.java

public class Movie {
    private List<PeriodCondition> periodConditions;
    private List<SequenceCondition> sequenceConditions;

    private boolean isDiscountable(Screening screening) {
        return checkPeriodConditions(screening) || checkSequenceConditions(screening);
    }

    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));
    }
}

이전에는 DiscountCondition 내부만 수정하면 됐지만, 이제는 Movie에도 변경의 영향을 미치고있다.
- DiscountCondition 입장에서는 응집도가 향상했지만, 변경과 캡슐화라는 관점에서 전체적으로 설계의 품질이 나빠졌다.

해결법2; 다형성을 통해 분리하기

Movie 입장에서는, PeriodCondition과 SequenceCondition은 아무 차이가 없다.
- 둘 모두 할인 여부를 판단하는 동일한 책임을 수행하고 있다.
  - 할인 여부 판단을 위한 방법이 다르다는 것을 Movie는 몰라도 괜찮다.
즉, Movie 입장에서 둘은 동일한 역할을 수행하고 있다.
- 역할은 협력 안에서 대체 가능성을 의미하며, 추상화를 통해 다양한 객체를 품을 수 있다.

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

public class PeriodCondition implements DiscountCondition {
	...
}

public class SequenceCondition implements DiscountCondition {
	...
}

public class Movie {
	private List<DiscountCondition> discountConditions;
    
    public Money calculateMovieFee(Screening screening) {
    	if (isDiscountable(screening)) {
        	return fee.minus(calculateDiscountAmount());
        }
    }
    
    return fee;
}

Movie와 DiscountCondition 사이의 협력은 다형적이다.
- 객체의 암시적인 타입에 따라 행동을 분기해야 한다면, 암시적인 타입을 명시적인 클래스로 정의하고 행동을 나눔으로써, 응집도 문제를 해결할 수 있다.
POLYMORPHISM(다형성) 패턴
- 객체의 타입에 따라 변하는 행동이 있다면, 타입을 분리하고 변화하는 행동을 각 타입의 책임으로 할당하는 것.

POLYMORPHISM(다형성) 패턴

객체의 타입에 따라 변하는 로직이 있을 때, 변하는 로직을 담당할 책임을 어떻게 할당해야 할까?

타입을 명시적으로 정의하고, 각 타입에 다형적으로 행동하는 책임을 할당해라.

조건에 따른 변화는 프로그램의 기본 논리다.

if ~ else, switch ~ case등 조건 논리를 이용해 설계한다면, 변화 시 조건 논리를 수정해야 한다.

이는 수정이 어렵고 변경에 취약하게 만든다.

조건적 논리를 이용하는 대신, POLYMORPHISM(다형성)을 이용해 새로운 변화를 다루기 쉽게 확장할 수 있다.

해결법3; 변경으로부터 보호하기

DiscountCondition이라는 추상화가 구체적인 구현을 캡슐화하고 있다.
- 새로운 타입이 추가되더라도, 추상화에 의존하는 Movie는 영향을 받지 않음을 의미한다.
  - 이처럼 변경을 캡슐화하도록 책임을 할당하는 것을 PROTECTED VARIATIONS(변경 보호) 패턴이라고 한다.

PROTECTED VARIATIONS(변경 보호) 패턴

객체, 서브시스템, 그리고 시스템을 어떻게 설계해야 변화와 불안정성이 다른 요소에 나쁜 영향을 미치지 않도록 방지할 수 있을까?

변화가 예상되는 불안정한 지점을 식별하고, 그 주위에 안정된 인터페이스를 형성하도록 책임을 할당해라.

설계에서 변하는 것이 무엇인지 고려하고 변하는 개념을 캡슐화하라.

📌 결론

하나의 클래스가 여러 타입의 행동을 구현하고 있는 것 처럼 보인다면,
- 클래스를 분리하고 POLYMORPHISM(다형성)으로 책임을 분산시켜라.
예측 가능한 변경으로 인해 클래스들이 불안정하다면,
- PROTECTED VARIATIONS(변경 보호)로 안정적인 인터페이스 뒤로 변경을 캡슐화해라.

🛠️ Movie 클래스 개선하기

Movie 역시 두가지 타입을 하나의 클래스 안에서 구현해, 여러개의 변경 이유를 가진다.
- 즉, 응집력이 낮다.
- 이 경우에도, POLYMORPHISM(다형성)을 이용해 개선할 수 있다.
Screening과 Movie가 메시지를 통해서만 다형적으로 협력하므로, 변화의 전파를 막을 수 있었다.
- 이는 PROTECTED VARIATIONS(변경 보호)를 통해 얻을 수 있는 장점이다.

Movie.java 개선

서로 다른 타입에서 요구되던 인스턴스 변수들이 삭제되었다.
- 자식 클래스에로 옮겨질 것이다.
공유해야 하는 구현이 있으므로, 추상클래스로 구현한다.
- calculateDiscountAmount 메서드를 추상 메서드로 선언해, 서브 클래스들이 할인 금액을 오버라이딩하도록 한다.

public class Movie {
    private String title;
    private Duration runningTime;
    private Money fee;
    private List<DiscountCondition> discountConditions;

    public Money calculateMovieFee(Screening screening) {
        if(isDiscountable(screening)) {
            return fee.minus(calculateDiscountAmount());
        }

        return fee;
    }

    public boolean isDiscountable(Screening screening) {
        return discountConditions.stream()
                .anyMatch(condition -> condition.isSatisfiedBy(screening));
    }
    
    abstract protected Money calculateDiscountAmount();

}

AmountDiscountMovie.java

금액 할인 정책
- Movie를 상속받아 구현을 재활용한다.

public class AmountDiscountMovie extends Movie {
    private Money discountAmount;
    
    public AmountDiscountMovie(
            String title,
            Duration runningTime,
            Money fee,
            Money discountAmount,
            DiscountCondition... discountConditions) {
        super(title, runningTime, fee, discountConditions);
        this.discountAmount = discountAmount;
    }
    
    @Override
    protected Money calculateDiscountAmount() {
        return discountAmount;
    }
}

PercentDiscountMovie.java

비율 할인 정책
- Movie를 상속받아 구현을 재활용한다.

public class PercentDiscountMovie extends Movie{
    private double percent;

    public PercentDiscountMovie(
            String title,
            Duration runningTime,
            Money fee,
            double percent,
            DiscountCondition... discountConditions) {
        super(title, runningTime, fee, discountConditions);
        this.percent = percent;
    }

    @Override
    protected Money calculateDiscountAmount() {
        return getFee().times(percent);
    }
}

할인 요금을 계산하기 위해 기본 금액을 제공하는 메서드를 추가한다.
- 서브클래스에서만 사용하도록, 가시성을 protected로 설정한다.

public abstract class Movie {
	protected Money getFee() {
    	return fee;
    }
}

NoneDiscountAmount.java

할인 미적용 정책
- Movie를 상속받아 구현을 재활용한다.

public class NoneDiscountAmount extends Movie{

    public NoneDiscountAmount(
            String title,
            Duration runningTime,
            Money fee) {
        super(title, runningTime, fee, discountConditions);
    }

    @Override
    protected Money calculateDiscountAmount() {
        return Money.ZERO;
    }
}

리팩토링 결과물
- 모든 클래스의 내부 구현은 캡슐화되어 있다.
- 모든 클래스는 하나의 변경 이유를 가지고 있다.
- 각 클래스는 응집도가 높고, 다른 클래스와 최대한 느슨하게 결합돼 있다.
- 클래스는 작고 오직 한 가지 일만 수행한다.
- 책임이 적절하게 분배돼 있다.
  - 책임을 중심으로 협력을 설계해 이러한 혜택을 얻을 수 있었다.

도메인의 구조가 코드의 구조를 이끈다.

최종 설계된 클래스의 구조가 초기 도메인 모델의 구조와 유사하다.

도메인 모델은 설계에 필요한 용어를 제공할 뿐만 아니라, 코드의 구조에도 영향을 미친다.

구현을 가이드할 수 있는 도메인 모델을 선택해라.

객체지향은 도메인의 개념과 구조를 반영한 코드를 가능하게 만들기 때문에, 도메인 구조가 코드의 구조를 이끌어 내는 것은 자연스럽고 바람직한 것이다.

변경과 유연성

변경에 대비하는 방법
1. 최대한 단순하게 설계 (코드 이해 및 수정이 편하도록)
2. 코드를 더 유연하게 만드는 것 (코드 수정 없이 변경이 가능하도록)

1번이 더 좋은 선택이지만, 유사한 변경이 반복적으로 발생한다면 복잡성이 상승하더라도 2번을 선택해 유연성을 추가할 수 있다.

상속(Inheritance)

현재는 할인 정책 구현을 위해 상속을 이용하고 있다.
- Movie 클래스를 상속 받아 각각의 할인 정책을 구현하고 있다.
- 할인 정책이 Movie의 하위클래스로 고정되어, 할인 정책 변경 시 새로운 Movie 객체를 생성해야 한다.

💻 할인 정책 변경 코드

할인 정책 변경 시, 새로운 인스턴스를 생성하고, 상태를 복사하고, 식별자를 관리하는 코드를 추가해야 한다. 이는 복잡하고 오류 발생 가능성이 높은 과정이다.

Movie movie = new AmountDiscountMoive("타이타닉", 10000, 1000);
// 할인 정책을 변경하려면 새로운 객체를 생성해야 함
movie = new PercentDiscountMovie("타이타닉", 1000, 0.1));

할인 정책 변경이 빈번하게 발생하는 경우, 이를 수용하기 힘든 상속 대신, 복잡성이 증가하더라도 변경에 유연한 합성을 사용할 수 있다.

합성(Composition)

할인 정책 변경을 고려하여 합성을 이용한다.
- Movie 클래스가 DiscountPolicy 인터페이스를 참조한다.
- 할인 정책을 독립적인 클래스로 분리한다.
- 실행 도중에도 할인 정책을 유연하게 변경할 수 있다.

💻 할인 정책 변경 코드

할인 정책 변경이 분리되어, 단순히 Movie의 DiscountPolciy의 인스턴스를 교체함으로써 할인 정책 변경을 구현할 수 있다.

Movie movie = new Movie("타이타닉", 10000, new AmountDiscountPolicy(1000));
// 나중에 할인 정책을 변경하고 싶다면
movie.changeDiscountPolicy(new PercentDiscountPolicy(0.1));

코드의 구조가 도메인의 구조에 대한 새로운 통찰력을 제공한다.

코드 구조의 변경은 곧 도메인에 대한 관점의 변화를 의미한다.
할인 정책의 자유로운 변경은, 도메인에 포함된 주요한 요구사항이다. 이 요구사항을 수용하기 위해 할인 정책이라는 개념을 코드 상에 명시적으로 드러냈다면, 도메인 모델 역시 코드의 관점에 따라 바뀌어야 한다.

도메인 모델은 구현과 밀접한 관계를 맺어야 한다. 도메인 모델은 코드에 대한 가이드를 제공해야 하며, 코드의 변화에 발맞춰 함께 변화해야 한다.

04. 책임 주도 설계의 대안

책임 주도 설계에 따라, 데이터가 아닌 책임 관점에서 설계를 고안하는 것은 어려운 작업이다. 이런 경우, 최대한 빠르게 목적한 기능을 수행하는 코드를 작성하고, 리팩터링하는 과정에서 좋은 설계를 얻을 수 있다.

리팩터링(refactoring)
- 이해하기 쉽고 수정하기 쉬운 소프트웨어로 개선하기 위해, 겉으로 보이는 동작은 바꾸지 않은 채 내부 구조를 변경하는 것.
- 이때, 코드 수정 후 겉으로 드러나는 동작은 바뀌어서는 안 된다.

객체 디자인에서 가장 기본이 되는 것 중의 하나(원칙은 아닐지라도)는 책임을 어디에 둘지를 결정하는 것이다. 나는 십년 이상 객체를 가지고 일했지만, 처음 시작할 때는 여전히 적당한 위치를 찾지 못한다. 늘 이런 점이 나를 괴롭혔지만, 이제는 이런 경우에 리팩터링을 사용하면 된다는 것을 알게 되었다.[Fowler 1999a]

메서드 응집도

데이터 중심 설계에서, 도메인 객체들은 단순히 데이터의 집합을 의미했다.
영화 예매의 모든 절차들은 ReservationAgency에 집중되어 있었다.
- ReservationAgency의 로직들을 적절한 객체의 책임으로 분배하면, 책임 주도 설계와 유사한 결과를 얻을 수 있다.

ReservationAgency.java

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();
        }

        return new Reservation(customer, screening, fee, audienceCount);
    }

}

reserve 메서드는 길이가 너무 길고 이해하기도 힘들다. 이런 메서드는 유지 보수에 부정적인 영향을 미친다. 마이클 패더스(Michael Feathers)는 이런 메서드를 몬스터 메서드(moster method)라고 부른다.

몬스터 메서드(moster method)
- 긴 메서드는 응집도가 낮아 이해하기도 어렵고, 재사용하기도 어려우며, 변경하기도 어렵다.
- 긴 메서드는 유지보수 측면에서 아래와 같은 부정적인 영향을 가진다.
  1. 어떤 일을 수행하는지 한눈에 파악하기 어렵기 때문에 코드를 전체적으로 이해하는 데 너무 많은 시간이 걸린다.
  2. 하나의 메서드 안에서 너무 많은 작업을 처리하기 때문에 변경이 필요할 때 수정해야 할 부분을 찾기 어렵다.
  3. 메서드 내부의 일부 로직만 수정하더라도 메서드의 나머지 부분에서 버그가 발생할 확률이 높다.
  4. 로직의 일부만 재사용하는 것이 불가능하다.
  5. 코드를 재사용하는 유일한 방법은 원하는 코드를 복사해서 붙여넣는 것뿐이므로 코드 중복을 초래하기 쉽다.

응집도가 낮은 메서드; 로직 흐름을 이해하기 위한 주석이 필요
- 메서드가 명령문들의 그룹으로 구성 + 각 그룹에 주석이 필요 => 응집도가 낮은 메서드
- 주석 추가 대신, 메서드를 작게 분해해서 각 메서드의 응집도를 높여야 함.

응집도 높은 메서드; 변경에 용이 (클래스처럼)
- 응집도가 높은 메서드는 변경 이유가 하나여야 한다.
- 작고, 목적이 명확한 메서드들로 구성된 클래스; 수정 부위 파악이 빠름
- 작은 메서드들로 조합된 메서드; 주석의 나열처럼 보여 코드 이해가 쉬움.

나는 다음과 같은 이유로 짧고, 이해하기 쉬운 이름으로 된 메서드를 좋아한다. 첫째, 메서드가 잘게 나눠져 있을 때 다른 메서드에서 사용될 확률이 높아진다. 둘째, 고수준의 메서드를 볼 때 일련의 주석을 읽는 것 같은 느낌이 들게 할 수 있다. 또한 메서드가 잘게 나눠져 있을 때 오버라이딩하는 것도 훨씬 쉽다. 만약 큰 메서드에 익숙해져 있다면 메서드를 잘게 나누는 데는 약간의 시간이 걸릴 것이다. 작은 메서드는 실제로 이름을 잘 지었을 때만 그 진가가 드러나므로, 이름을 지을 때 주의해야 한다.
사람은 때때로 나에게 한 메서드의 길이가 얼마나 돼야 할지를 묻는다. 그러나 나는 길이가 중요하다고 생각하지 않는다. 중요한 것은 메서드의 이름과 메서드 몸체의 의미적 차이다. 뽑아내는 것이 코드를 더욱 명확하게 하면 새로 마든 메서드의 이름이 원래 코드의 길이보다 길어져도 뽑아낸다.[Fowler99a]

🛠️ 리팩터링 한 ReservationAgency.java

public class ReservationAgencyRefactor {
    public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
        boolean discountable = checkDiscountable(screening);
        Money fee = calculateFee(screening, audienceCount, discountable);
        return createReservation(customer, screening, fee, audienceCount);
    }

    private boolean checkDiscountable(Screening screening) {
        return screening.getMovie().getDiscountConditions().stream()
                .anyMatch(condition -> isDiscountable(screening, condition));
    }

    private boolean isDiscountable(Screening screening, DiscountCondition condition) {
        if (condition.getType() == DiscountConditionType.PERIOD) {
            return isSatisfiedByPeriod(screening, condition);
        }
        return isSatisfiedBySequence(screening, condition);
    }

    private boolean isSatisfiedBySequence(Screening screening, DiscountCondition condition) {
        return condition.getSequence() == screening.getSequence();
    }

    private boolean isSatisfiedByPeriod(Screening screening, DiscountCondition condition) {
        return screening.getWhenScreened().getDayOfWeek().equals(condition.getDayOfWeek())
                && condition.getStartTime().compareTo(screening.getWhenScreened().toLocalTime()) <= 0
                && condition.getEndTime().compareTo(screening.getWhenScreened().toLocalTime()) >= 0;
    }

    private Money calculateFee(Screening screening, int audienceCount, boolean discountable) {
        if (discountable) {
            return screening.getMovie().getFee()
                    .minus(calculateDiscountedFee(screening.getMovie()))
                    .times(audienceCount);
        }

        return screening.getMovie().getFee();
    }

    private Money calculateDiscountedFee(Movie movie) {
        switch(movie.getMovieType()) {
            case AMOUNT_DISCOUNT:
                return calculateNoneDiscountedFee(movie);
            case PERCENT_DISCOUNT:
                return calculatePercentDiscountedFee(movie);
            case NONE_DISCOUNT:
                return calculateAmountDiscountedFee(movie);
        }

        throw new IllegalArgumentException();
    }

    private Money calculateNoneDiscountedFee(Movie movie) {
        return movie.getFee();
    }

    private Money calculatePercentDiscountedFee(Movie movie) {
        return movie.getFee().times(movie.getDiscountPercent());
    }

    private Money calculateAmountDiscountedFee(Movie movie) {
        return movie.getDiscountAmount();
    }

    private Reservation createReservation(Screening screening, Customer customer,
                                          int audienceCount, Money fee) {
        return new Reservation(customer, screening, fee, audienceCount);
    }

}

리픽토링 후
- 오직 하나의 작업만을 수행하고, 하나의 변경이유만 가지는, 작고 명확하고 응집도가 높은 메서드들로 구성
- 클래스의 길이가 길어졌으나, 명확성의 가치가 클래스의 길이보다 더 중요하다.
- 조그마한 부분에서 개선된 명확성이 모여 변경이 쉬운 코드가 만들어진다.

public 메서드는 상위 수준의 명세를 읽는 것 같은 느낌을 준다.
- 메서드가 어떤 일을 하는지 한눈에 알아볼 수 있다.
- 메서드의 구현이 주석을 모아놓은 것처럼 보인다.

    public Reservation reserve(Screening screening, Customer customer, int audienceCount) {
        boolean discountable = checkDiscountable(screening);
        Money fee = calculateFee(screening, audienceCount, discountable);
        return createReservation(customer, screening, fee, audienceCount);
    }

코드를작은 메서드들로 분해하면
- 전체적인 흐름을 이해하기 쉬워진다.
  - 한번에 기억해야 할 정보를 줄일 수 있기 때문이다.
    - 동시에 너무 많은 세부사항을 기억할 필요가 없다.
    - 세부적인 정보가 필요한 경우, 그때 해당 메서드의 세부 구현을 확인하면 된다.
- 변경하기 쉬어진다.
  - 각 메서드는 단 하나의 이유에 의해서만 변경된다.
작고, 명확하며, 한 가지 일에 집중하는 응집도 높은 메서드는 변경 가능한 설계를 이끌어내는 기반이 된다.

객체를 자율적으로 만들자

메서드의 완성도에도 불구하고, ReservationAgency의 응집도는 여전히 낮다.
- 응집도를 높이기 위해, 변경의 이유가 다른 메서드들을 적절한 위치로 분배해야 한다.
어떤 메서드를 어떤 클래스로 이동시켜야 할까?
- 객체는 자율적인 존재여야 한다.
  - 자신이 소유하고 있는 데이터를 스스로 처리하도록 만들어야 한다.

📌 결론

책임주도 설계 방법에 익숙하지 않다면, 일단 데이터 중심으로 구현한 후에 리팩토링 하더라도 유사한 결과를 얻을 수 있다.

Reference

오브젝트 | 조영호

bien

Good Luck!

이전 포스트

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

다음 포스트

[오브젝트] #5. 책임 할당하기

오브젝트

01. 책임 주도 설계를 향해

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

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

책임 주도 설계

02. 책임 할당을 위한 GRASP 패턴

도메인 개념에서 출발하기

올바른 모델이란 존재하지 않는다.

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

1단계; App이 제공해야 하는 기능을, 애플리케이션의 책임으로 간주

정보 전문가 패턴(INFORMATION EXPERT)

📌 결론

높은 응집도와 낮은 결합도

LOW COUPLING (낮은 결합도)

LOW COUPLING 패턴

HIGH COHESION (높은 응집도)

HIGH COHESION 패턴

Screnning 의 경우

Movie 의 경우

📌 결론

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

CREATOR 패턴

03. 구현을 통한 검증

Screening

결과물 💻 Screening.java

Movie

결과물 💻 Movie.java

DiscountCondition

결과물 💻 DiscountCondition.java

코드추가 💻 Screening.java

🛠️ DiscountCondition 개선하기

문제점; 변경 이유가 하나 이상인 클래스

📌 클래스의 응집도 파악

해결법1; 타입 분리하기

PeriodCondition.java

SequenceCondition.java

Movie.java

해결법2; 다형성을 통해 분리하기

POLYMORPHISM(다형성) 패턴

해결법3; 변경으로부터 보호하기

PROTECTED VARIATIONS(변경 보호) 패턴

📌 결론

🛠️ Movie 클래스 개선하기

Movie.java 개선

AmountDiscountMovie.java

PercentDiscountMovie.java

NoneDiscountAmount.java

도메인의 구조가 코드의 구조를 이끈다.

변경과 유연성

상속(Inheritance)

💻 할인 정책 변경 코드

합성(Composition)

💻 할인 정책 변경 코드

코드의 구조가 도메인의 구조에 대한 새로운 통찰력을 제공한다.

04. 책임 주도 설계의 대안

메서드 응집도

ReservationAgency.java

🛠️ 리팩터링 한 ReservationAgency.java

객체를 자율적으로 만들자

📌 결론

Reference

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

[오브젝트] #6. 메시지와 인터페이스

0개의 댓글