TIL

02 객체지향 프로그래밍

01 영화 예매 시스템

• ‘영화’
  • 영화에 대한 기본 정보 (제목, 상영시간, 가격 정보 등)
• ‘상영’
  • 실제 영화를 관람하는 사건 (상영 일자, 시간, 순번 등)
  • 하나의 영화는 하루에 여러번 상영될 수 있다.
  • 사람들은 영화를 예매한다고 표현하지만 실제로는 상영되는 영화를 관람할 수 있는 권리를 구매하는 것
• ‘할인 조건’
  • 가격의 할인 여부를 결정
  • ‘순서 조건’ - 상영 순번을 이용해 할인 여부 결정
  • ‘기간 조건’ - 영화 상영 시작 시간을 이용해 할인 여부 결정
  • 다수의 할인 조건을 함께 지정할 수 있고 순서 조건과 기간 조건을 섞는 것도 가능하다.
• ‘할인 정책’
  • 할인 요금을 결정
  • ‘금액 할인 정책’ - 일정 금액을 할인하는 방식
  • ‘비율 할인 정책’ - 일정 비율의 요금을 할인하는 방식
  • 영화별로 하나의 할인 정책만 할당 가능
  • 할인 정책은 1인 기준으로 책정된다.

02 객체지향 프로그래밍을 향해

• 어떤 클래스(class)가 필요한지 먼저 고민한다면 그것은 객체지향의 본질과는 거리가 멀다.
• 클래스를 고민하기 전에 어떤 객체들이 필요한지 고민하라
  • 어떤 객체가 어떤 상태와 행동을 가지는지
• 객체를 독립적인 존재가 아닌 협력하는 공동체의 일원으로 봐야 한다.

도메인의 구조를 따르는 프로그램 구조

• 도메인
  • 소프트웨어를 만들 때 문제를 해결하기 위해 사용하는 분야를 뜻한다.
• 객체지향 패러다임이 강력한 이유
  • 요구사항을 분석하는 초기 단계부터 구현하는 마지막 단계까지 객체라는 동일한 추상화 기법을 사용할 수 있기 때문

클래스 구현하기

• Screening (상영)

    public class Screening {
        private Movie movie;
        private int sequence;
        private LocalDateTime whenScreened;
      
        public Screening(Movie movie, int sequence, LocalDateTime whenScreened) {
            this.movie = movie;
            this.sequence = sequence;
            this.whenScreened = whenScreened;
        }
      
        public LocalDateTime getStartTime() {
            return whenScreened;
        }
      
        public boolean isSequence(int sequence) {
            return this.sequence == sequence;
        }
      
        public Money getMovieFee() {
            return movie.getFee();
        }
      
        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);
        }
    }
  

  • 인스턴스 변수는 private, 메서드는 public

클래스를 구현하거나 사용할 때 가장 중요한 것은 클래스 경계를 구분 짓는 것. 훌륭한 설계의 핵심은 어떤 부분을 공개하고 숨길지 결정하는 것. 경계의 명확성이 객체의 자율성을 보장한다.

• 자율적인 객체
  • 객체는 ‘상태’와 ‘행동’을 함께 지니는 복합적 존재
  • 상태와 행동을 캡슐화해야 한다.
  • 캡슐화와 접근 제어 메커니즘을 통해 객체를 자율적인 존재로 만들 수 있다.
  • 캡슐화와 접근 제어의 측면에서 객체는 ‘퍼블릭 인터페이스’와 ‘구현’으로 나뉜다.
  • 인터페이스와 구현의 분리(separation of interface and implementation) 원칙을 따라야 한다.
  • 객체는 상태는 숨기고 행동만 외부에 공개해야 한다.
• 프로그래머의 자유
  • 프로그래머는 ‘클래스 작성자’와 클라이언트 프로그래머’로 구분된다.
  • ‘클라이언트 프로그래머’의 목표는 필요한 클래스를 엮어 애플리케이션을 빠르고 안정적으로 구축하는 것
  • ‘클래스 작성자’의 목표는 ‘클라이언트 프로그래머’에게 필요한 부분만 공개하고 나머지는 숨기는 것 → 구현 은닉

협력하는 객체들의 공동체

• 영화 예매 기능을 만들어보자.
  • Screening.reserve() 메서드는 예매 후 예매 정보를 가지는 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.cacluateFee() 메서드로 반환된 Money 객체가 times() 메서드를 통해 인원 수만큼의 가격을 곱한다.
    • Money 코드
    • Money 객체를 통해 돈과 관련된 로직의 중복 구현을 막고 도메인 의미를 풍부하게 표현할 수 있다.

• Reservation 클래스

    public class Reservation {
        private Customer customer; // 고객
        private Screening Screening; // 상영 정보
        private Money fee; // 예매 요금
        private int audienceCount; // 인원 수
      
        public Reservation(Customer customer, Screening Screening, Money fee, int audienceCount) {
            this.customer = customer;
            this.Screening = Screening;
            this.fee = fee;
            this.audienceCount = audienceCount;
        }
    }
  

  • Screening, Movie, Reservation 인스턴스들은 서로 호출하며 상호작용하는데 이를 ‘협력’이라 부른다.
  • Screening → Reservation 생성
  • Screening → Movie 사용 (calculateFee)
• 객체지향 프로그램을 작성할 때는
  • 협력 관점에서 어떤 객체가 필요할지 결정하고
  • 공통 상태와 행위를 구현하기 위해 클래스를 작성한다.

협력에 관한 짧은 이야기

• 객체 내부 상태는 외부에서 접근하지 못하지만 퍼블릭 인터페이스를 통해선 내부 상태에 접근 가능하다.
• 객체는 다른 객체의 인터페이스를 통해 행동을 ‘요청’할 수 있고 요청 받은 객체는 자율적으로 행동한 후 ‘응답’한다.
• 객체 간 상호작용의 유일한 방법은 ‘메시지 전송’과 ‘매시지 수신’이다.
  • 수신된 메시지를 처리하기 위한 자신만의 방법을 ‘메서드(method)’라 부른다.
• 메서드와 메시지를 구분하는 것은 매우 중요
  • 다형성 개념의 출발

03 할인 요금 구하기

할인 요금 계산을 위한 협력 시작하기

• Movie 클래스

    public class Movie {
        private String title;
        private Duration runningTime;
        private Money fee;
        private DiscountPolicy discountPolicy;
      
        public Movie(String title, Duration runningTime, Money fee, DiscountPolicy discountPolicy) {
            this.title = title;
            this.runningTime = runningTime;
            this.fee = fee;
            this.discountPolicy = discountPolicy;
        }
      
        public Money calculateMovieFee(Screening screening) {
            return fee.minus(discountPolicy.calculateDiscountAmount(screening));
        }
      
        // ...
    }
  

  • caculateMovieFee 메서드는 discountPolicy에 메시지를 전송해 할인 요금을 반환 받는다.
  • 위 메서드에는 어떤 할인 정책(금액 할인 or 비율 할인)을 선택하는지 드러나 있지 않고 discountPolity에 메시지를 전송할 뿐이다.
  • 위 코드에는 ‘상속’과 ‘다형성’ 개념이 숨겨져 있고 그 기반에는 ‘추상화’라는 원리가 숨겨져 있다.

할인 정책과 할인 조건

• AmounDiscountPolicy와 PercentDiscountPolicy는 대부분 코드가 유사하고 요금을 계산하는 방식만 조금 다르다.
  • 중복 코드를 보관할 장소가 필요

• 부모 클래스인 DiscountPolicy에 중복 코드를 두고 각 구현체가 이를 상속 받게 한다.

    public abstract class DiscountPolicy {
        private List<DiscountCondition> conditions = new ArrayList<>();
      
        public DiscountPolicy(DiscountCondition ... conditions) {
            this.conditions = Arrays.asList(conditions);
        }
      
        public Money calculateDiscountAmount(Screening screening) {
            return conditions.stream()
                    .filter(each -> each.isSatisfiedBy(screening))
                    .findFirst()
                    .map(each -> getDiscountAmount(screening))
                    .orElse(Money.ZERO);
        }
      
        abstract protected Money getDiscountAmount(Screening Screening);
    }
  

  • 어떤 할인 정책 구현체도 ‘할인 조건을 하나라도 만족하면 할인을 적용한다’는 부분은 공통이므로 추상 클래스에 해당 로직을 두었다.
  • 할인 금액을 적용하는 부분만 추상 메서드로 남겨두어 각 구현체가 오버라이드하도록 했다.
  • 이처럼 부모 클래스에 기본 알고리즘을 구현하고 필요한 처리를 자식에게 위임하는 디자인 패턴을 템플릿 메서드 패턴이라고 부른다.

• DiscountCondition은 인터페이스로 선언되어 있다.

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

• 각 할인 정책과 할인 조건 구현체의 구현 코드는 아래에서 확인할 수 있다.

    public class SequenceCondition implements DiscountCondition { // 순번 조건
        private int sequence;
      
        public SequenceCondition(int sequence) {
            this.sequence = sequence;
        }
      
        public boolean isSatisfiedBy(Screening screening) {
            return screening.isSequence(sequence);
        }
    }
      
    public class PeriodCondition implements DiscountCondition { // 기간 조건
        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 screening.getStartTime().getDayOfWeek().equals(dayOfWeek) &&
                    startTime.compareTo(screening.getStartTime().toLocalTime()) <= 0 &&
                    endTime.compareTo(screening.getStartTime().toLocalTime()) >= 0;
        }
    }
      
    public class AmountDiscountPolicy extends DiscountPolicy { // 금액 할인 정책
        private Money discountAmount;
      
        public AmountDiscountPolicy(Money discountAmount, DiscountCondition... conditions) {
            super(conditions);
            this.discountAmount = discountAmount;
        }
      
        @Override
        protected Money getDiscountAmount(Screening screening) {
            return discountAmount;
        }
    }
      
    public class PercentDiscountPolicy extends DiscountPolicy { // 비율 할인 정책
        private double percent;
      
        public PercentDiscountPolicy(double percent, DiscountCondition... conditions) {
            super(conditions);
            this.percent = percent;
        }
      
        @Override
        protected Money getDiscountAmount(Screening screening) {
            return screening.getMovieFee().times(percent);
        }
    }
  

할인 정책 구성하기

• 생성자를 통해 객체가 올바른 상태로 있을 수 있도록 강제할 수 있다.

  • 영화에 대해선 단 하나의 할인 정책만 설정 가능

    → Movie 생성자에 하나의 정책만 받음

  • 할인 정책에 여러 할인 조건을 적용 가능

    → DiscountPolicy 생성자에 여러 정책 받음

Movie avater = new Movie("아바타", 
    Duration.ofMinutes(120),
    Money.wons(10000),
    new AmountDiscountPolicy(Money.wons(800),
        new SequenceCondition(1),
        new SequenceCondition(10),
        new PeriodCondition(...), 
        new PeriodCondition(...))));

04 상속과 다형성

• Movie 클래스 어디에도 할인 정책을 판단하지 않는다.
• 할인 정책 판단 조건문 코드가 없음에도 동작하는 이유는 상속과 다형성 덕분이다.

컴파일 시간 의존성과 실행 시간 의존성

• 코드의 의존성과 실행 시점 의존성은 서로 다를 수 있다.
  • Movie는 DiscountPolicy를 의존하지만, 실행 시간에는 구현체 중 하나를 의존하게 된다.
• 컴파일 시간, 실행 시간 의존성이 다른 것에도 트레이드 오프가 존재한다.
  • 코드를 이해하고 디버깅하기 어려워 진다.
  • 코드는 더 유연해지고 확장 가능해진다.
• 무조건 유연한 설계도, 모조건 읽기 쉬운 코드도 정답이 아니다.
  • 항상 고민하자

차이에 의한 프로그래밍

• 상속은 객체지향에서 코드를 재사용하기 위해 가장 널리 사용되는 방법
  • 부모 클래스 구현을 공유하며 행동이 다른 자식 클래스를 쉽게 추가 가능

• 부모 클래스와 다른 부분만 추가해서 새로운 클래스를 더 쉽고 빠르게 만드는 방법

  → 차이에 의한 프로그래밍(programming by differnce)

상속과 인터페이스

• 상속이 가치 있는 이유
  • 부모 클래스의 모든 인터페이스를 자식 클래스가 물려 받을 수 있다.
  • 즉 자식 클래스는 부모 클래스가 수신 가능한 모든 메시지를 수신할 수 있어 외부에서 동일 타입으로 간주될 수 있다.
• 외부 객체 입장에서 동일한 메시지를 수신할 수 있다면 그 구현체가 무엇인지는 상관하지 않는다.
• 업캐스팅
  • 자식 클래스가 부모 클래스를 대신할 수 있는 것
  • 타입이 부모 클래스여도 자식 클래스의 인스턴스를 전달할 수 있다.

다형성

• 다시 강조하지만 메시지와 메서드는 다른 개념이다.
• 동일한 메시지를 보내도 런타임에 다형성에 의해 어떤 메서드가 호출 될지는 알 수 없다.
  • Movie에 메시지 → ‘할인 정책을 적용해 비용을 계산해라’
  • 호출되는 메서드 → AmoundDiscountPolicy.getDiscountAmount() or PercentDiscountPolicy.getDiscountAmount()
• 다형성이란
  • 동일한 메시지를 수신했을 때 객체 타입에 따라 다르게 응답할 수 있는 능력을 의미
  • 협력에 참여하는 객체는 같은 메시지를 이해할 수 있어야 한다. (인터페이스가 같아야 함)
• 객체지향이 다형성을 구현할 수 있는 이유
  • 지연 바인딩(동적 바인딩) 메커니즘을 사용
  • 메시지와 메서드를 실행 시점에 바인딩
  • 그에 반해 전통적 함수 호출은 컴파일 시점에 함수나 프로시저를 결정 (초기 바인딩, 정적 바인딩)
• 구현 상속과 인터페이스 상속
  • 구현 상속 - 상속, 서브 클래싱
    • 순수하게 코드를 재사용하기 위한 목적
    • 다형적인 협력을 위해 부모와 자식이 인터페이스를 공유
  • 인터페이스 상속 - 인터페이스를 통한 상속, 서브 타이핑
  • 상속은 인터페이스 상속을 사용해야 한다.
    • 상속의 주된 목적은 인터페이스를 재사용하기 위해
    • 구현을 재사용할 목적으로 사용하면 안 된다.
    • 구현을 재사용하면 변경에 취약해진다.

인터페이스와 다형성

• 종종 구현은 공유할 필요가 없고 순수하게 인터페이스만 공유하고 싶을 때가 있다.
  • 앞서 DiscountPolicy는 추상 클래스를 사용해 구현 상속을 사용했다.
• 순수하게 인터페이스(메시지)만 공유하고 싶을 때 인터페이스를 사용할 수 있다.
  • 인터페이스로 구현에 대한 고려 없이 협력에 필요한 공유 메시지를 정의할 수 있다.
• DiscountCondition의 경우 구현 공유가 필요 없었기에 인터페이스를 사용했었다.

05 추상화와 유연성

추상화의 힘

• 추상화 계층만 따로 보면 요구사항 정책을 높은 수준에서 서술할 수 있다.
  • 할인 정책과 할인 조건이라는 추상적인 개념을 통해 다양한 조건과 정책들을 활용한 요구사항을 포괄할 수 있다.
    • ex) ‘영화 예매 요금은 최대 하나의 ‘할인 정책’과 다수의 ‘할인 조건’을 이용해 계산할 수 있다.’
  • 세부 내용을 무시하고 상위 정책을 간단하게 표현 가능
• 설계가 유연해진다.
  • 추상화를 통해 상위 정책을 표현하면 기준 구조 수정 없이 새로운 기능을 쉽게 추가, 확장 가능하다.

유연한 설계

• 할인 정책이 없는 경우는 어떻게 할까?

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

  • 위 코드 문제점: 일관적이던 협력 방식이 무너진다.
  • 할인 정책이 없는 경우 0원이라는 사실을 의사 결정을 Movie 내부에서 결정하게 된다.

책임의 위치를 결정하기 위해 조건문을 사용하는 것은 협력적인 설계 측면에서 대부분 좋지 않은 선택이다. (할인 금액 계산 책임의 위치가 Movie이냐, DiscoutPolicy냐가 조건문에 의해 나뉘고 있다.)

• NoneDiscountPolicy를 통해 일관성을 지킬 수 있다.

    public class NoneDiscountPolicy extends DiscountPolicy {
        @Override
        protected Money getDiscountAmount(Screening screening) {
            return Money.ZERO;
        }
    }
  

• 중요한 것은 Movie와 DiscountPolicy는 수정하지 않고 클래스를 추가하는 것만으로 기능을 확장했다는 것

추상 클래스와 인터페이스 트레이드 오프

• NoneDiscountPolicy는 할인 조건이 없기 때문에 getDiscountAmount() 반환 값이 의미가 없다.
  • 부모 클래스인 DiscountPolicy에서 할인 조건에 매칭되는 경우에만 getDiscountAmount()를 호출한다.
• 위 문제는 DiscountPolicy와 NoneDiscountPolicy를 개념적으로 결합시킨다.
  • NoneDiscountPolicy를 만든 개발자는 getDiscountAmount()가 호출되지 않을 경우 DiscountPolicy가 0원을 반환할 것이라는 걸 가정하기 때문
  • 애초에 지금의 추상 클래스인 DiscountPolicy는 할인 조건을 탐색하는 공통 로직이 존재하는데 NoneDiscountPolicy에게는 필요 없는 절차이다.

• DiscountPolicy를 인터페이스로 변경하자

  

    public interface DiscountPolicy {
        Money calculateDiscountAmount(Screening screening);
    }
      
    // NoneDiscountPolicy는 DiscountPolicy를 바로 구현
      
    public abstract class DefaultDiscountPolicy implements DiscountPolicy { // 할인 조건 탐색이 필요한 경우
        private List<DiscountCondition> conditions = new ArrayList<>();
      
        public DefaultDiscountPolicy(DiscountCondition... conditions) {
            this.conditions = Arrays.asList(conditions);
        }
      
        @Override
        public Money calculateDiscountAmount(Screening screening) {
            // 할인 정책 탐색 코드 존재
            // ...
        }
      
        abstract protected Money getDiscountAmount(Screening Screening);
    }
      
    // AmountDiscoutPolicy와 PercentDiscountPolicy는 DefaultDiscountPolicy를 상속
  

모든 구현과 관련된 것들은 트레이드 오프의 대상이다. 사소한 결정이라도 트레이드오프를 통해 얻어진 결론과 그렇지 않은 결론의 차이는 크다. 고민하고, 트레이드오프하라.

코드 재사용

• 상속 보다 합성(composition)’이라는 얘기를 들어봤을 것이다.
  • 합성 - 다른 객체 인스턴스를 자신의 인스턴스 변수로 포함해 재사용 하는 방법
  • Movie가 DiscountPolicy의 코드를 재사용하는 방법이 바로 합성
• Movie가 DiscountPolicy를 상속해서 사용하도록 변경할 수도 있다.
• 그런데 왜 합성을 더 선호할까?

상속

• 상속의 단점
  • 상속이 캡슐화를 위반
  • 설계를 유연하지 못하게 만든다.
• 캡슐화 위반
  • 상속을 하려면 부모 클래스 내부 구조를 잘 알아야 한다.
  • 자식 클래스에게 부모 클래스 내부 구현이 노출된다.
  • 부모 클래스를 변경할 때 자식 클래스도 변경될 확룔이 높다.
  • 과도한 상속은 변경하기 어렵게 만든다.
• 설계가 유연하지 않다.
  • 부모, 자식 관계는 컴파일 시점에 결정된다.
  • 실행 시점에 객체 종류를 변경하는 것이 불가능하다.
  • 합성을 이용한다면 내부 의존성만 변경하면 다른 정책을 사용할 수 있다.

합성

• 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 합성이라 한다.
• 합성은 상속의 두 문제점을 모두 해결한다.
  • 메시지를 통해 협력하기에 캡슐화 가능
  • 의존하는 인스턴스 교체를 통해 설계가 유연
• 상속을 절대 사용하지 말라는 말은 아니다.
  • 코드를 재사용하는 경우에는 상속보다 합성을 선호
  • 하지만 다형성을 위해 인터페이스를 재사용하는 경우에는 상속과 합성을 조합해서 사용할 수밖에 없다.