[오브젝트 2장] - 객체지향 프로그래밍

[오브젝트 2장] - 객체지향 프로그래밍

 

- 모든 이미지의 출처는 오브젝트(조용호 저) 책 입니다.

 

 

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

 

객체지향 프로그래밍은 클래스를 먼저 고민하는 것이 아니라 객체에 집중해야 한다. 다음 두 가지를 집중해보자.

 

1) 어떤 클래스가 필요한지를 고민하기 전에 어떤 객체가 필요한지 고민하자. 어떤 객체들이 어떤 행동을 하고 어떤 상태를 가지는지를 먼저 결정한다.

2) 객체를 독립적인 존재가 아니라 협력하는 공동체의 일원으로 바라봐야 한다. 

 

 

 

 

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

 

도메인은 사용자의 문제를 해결하기 위해 프로그램을 사용하는 분야를 일컫는다. 영화예매 프로그램에서 '영화예메'는 도메인에 속한다. 

 

객체지향 패러다임이 강력한 이유는 요구사항을 분석하는 초기 단계부터 프로그램을 구현하는 마지막 단계까지 동일한 추상화 기법을 사용할 수 있기 때문이다. 요구사항과 프로그램을 객체라는 동일한 관점에서 바라볼 수 있기 때문에 도메인을 구성하는 개념들이 프로그램의 객체와 클래스로 매끄럽게 연결될 수 있다. 

 

 

 

영화는 여러 번 상영될 수 있고, 상영은 여러 번 예매 될 수 있다는 것을 알 수 있다. 또한 영화는 할인정책이 있을 수도 있고, 할인 정책이 존재한다면 할인 조건이 반드시 하나 이상이 존재해야 함을 알 수 있다. 

 

도메인의 구조를 클래스와 매칭 시키면 다음과 같아진다. 

 

 

 

 

 

 클래스 구현하기

 

 

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 geetStartTime() {
        return whenScreened;
    }
    
    public boolean isSequence(int sequence) {
        return this.sequence == sequence;
    }
    
    public Money getMovieFee() {
        return movie.getFee();
    }
}

 

클래스를 작성할 때 중요한 것은 내부와 외부를 경계짓는 것이다. 이러한 경계가 명확하면 명확할 수록 객체 스스로가 상태를 쉽게 변경할 수 있기 때문에 자율성을 보장한다. 이렇게 되면 프로그래머에게 구현의 자유를 제공하게 된다.  -> 어느 곳에서 변경될 지를 명확하게 아니까 변경의 자유(구현의 자유)가 생기는 것.

 

객체는 1) '상태'와 '행동'을 함께 가지는 복합적인 존재이면서 2) 스스로 판단하고 행동하는 '자율적인 존재'이다. 

 

객체지향 프로그래밍 언어들은 대부분 접근제어자를 지원한다.

객체 내부를 통제하는 이유는 객체를 자율적인 존재로 만들기 위해서다. 객체지향의 핵심은 스스로 상태를 관리하고, 판단하고, 행동하는 자율적인 객체들의 공동체를 구성하는 것이다. 외부에서 객체의 상태를 변경하게 된다면 객체가 자율적인 존재가 되지 못한다. 

 

직접 개입하지 말고 원하는 걸 요청하고 스스로 최선의 결정을 내리도록 기다리자. 

 

인터페이스와 구현을 분리해야 하는 가장 큰 이유는 변경에 용이하기 위해서임을 기억하자.

 

클라이언트는 인터페이스를 통해서 구체적인 객체의 내부 구현을 알 필요가 없다. 시간절약인 셈이다. 더불어 구현내용에 알고리즘을 추가하거나 로직을 바꾸더라도 클라이언트의 코드는 변하지 않는다.  따라서 클래스 작성자는 인터페이스와 구현을 깔끔하게 분리하기 위해 노력해야 한다. 

 

 

 

 

 협력하는 객체들의 공동체

 

public class Money {
    public static final Money ZERO = Money.wons(0);
    
    private final BigDecimal amount;
    
    public static Money wons(BigDecimal amount) {
        return new Money(BigDecimal.valueOf(amount));
    }
}

 

Money 타입 대신에 long 타입을 사용할 수는 있지만 '금액'이라는 의미를 전달할 수는 없다. 또한 금액과 관련된 로직을 Money타입에 담을 수 있기 때문에 중복코드를 줄일 수 있다. 객체지향의 장점은 객체를 이용해 도메인의 의미를 풍부하게 표현할 수 있다는 것이다.  

따라서 의미를 좀 더 명시적이고 분명하게 표현할 수 있다면 객체를 이용해서 해당 개념을 구현하라.  그 개념이 비록 인스턴스 변수를 포함하더라도 말이다. 

 

객체가 다른 객체와 상호작용할 수 있는 방법은 메시지를 전송하는 것 뿐이다. 이와 유사한 개념으로 메서드가 있는데, 메서드는 수신된 메시지를 처리하기 위한 자신만의 방법을 의미한다. 

 

 

 

 할인 요금 구하기

 

영화예매 금액을 구할 할인 정책 클래스를 만들어보자. 

 

먼저 할인 정책은 금액 할인 정책과 비율 할인 정책으로 구분된다. 두 가지 할인 정책을 각각 AmountDiscountPolicy와 PercentDiscountPolicy로 구분한다. 두 클래스는 유사하기 때문에 중복 코드를 제거하기 위해 공통 코드를 보관할 장소가 필요하다. 따라서 추상 클래스를 사용해보자.

 

public abstract class DiscountPolicy {
    private List<DiscountCondition> conditions = new ArrayList<>();
    
    public DiscountPolicy(DiscountCondition ... conditions) {
        this.conditions = conditions;
    }
    
    public Money calculateDiscountAmount(Screening screening) {
        for(DiscountCondition each : conditions) {
            if (each.isSatisFiedBy(screening)) {
                return getDiscountAmount(screening)
            }
        }
        
        return Money.ZERO;
    }
    
    abstract Money getDiscountAmount(Screening screening);
}

 

할인 조건을 만족하는 DiscountCondition이 하나라도 존재하는 경우에는 '추상 메서드'인 getDiscountAmount를 호출해서 할인 요금을 계산한다.

 

DiscountPolicy는 할인 여부와 계산하는 흐름을 정의하지만 실제로 계산하는 부분은 자식 클래스에서 오버라이딩 한 메서드에 위임한다. 이처럼 부모클래스에 기본적인 알고리즘을 구현하고 중간에 필요한 처리를 자식 클래스에 위임하는 디자인 패턴을 'TEMPLATE METHOD'(템플릿 메서드) 패턴이라고 한다.

 

 

DiscountCondition은 자바의 인터페이스로 구현한다. 

 

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

 

 

그리고 이 인터페이스를 구현하는 순서조건과 기간 조건을 구현한다.

 

public class SequenceCondition implements DiscountCondition {
    private int sequence;

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

    @Override
    public boolean isSatisfied(Screening screening) {
        return false;
    }
}

 

 

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

    @Override
    public boolean isSatisfied(Screening screening) {
        return screening.getStartTime().getDayOfWeek().equals(dayOfWeek) &&
                startTime.compareTo(screening.getStartTime().toLocalTime()) <= 0 &&
                endTime.compareTo(screening.getStartTime().toLocalTime()) >= 0;
    }
}

 

 

다음으로는 할인 정책을 구현하자. AmountDiscountPolicy는 DiscountPolicy의 자식 클래스로서 할인 조건을 만족할 경우 일정한 금액을 할인해준다. 

 

public class AmountDiscountPolicy implements DiscountPolicy {
    private Money discountAmount;
    
    public AmountDiscountPolicy(Money discountAmount, DiscountCondition ... conditions) {
        super(conditions);
        this.discountAmount = discountAmount;
    }
    
    @Override
    Money getDiscountAmount(Screening screening) {
        return discountAmount;
    }
}

 

PercentDiscountPolicy 역시 getDiscountAmount 메서드를 오버라이딩하여 구현한다.

 

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

 

 

정책에 관한 구현클래스들은 추상클래스를 상속받고 있기 때문에 super를 통해 부모클래스를 초기화해준다. 

 

위 코드들은 생성자를 통해서 초기화에 필요한 정보를 올바르게 전달하도록 강제하고 있다. 이를 통해 할인 정책은 한 영화당 한 개만 적용하고, 할인 조건은 여러 개를 적용할 수 있도록 해준다. 

 

이제 클라이언트 측에서 코드를 사용하면 다음과 같아진다. 

 

Movie titanic = new Movie("타이타닉",
        Duration.ofMinutes(180),
        Money.wons(11000),
        new PercentDiscountPolicy(0.1),
                new PeriodCondition(DayOfWeek.TUESDAY, LocalTime.of(14, 0), LocalTime.of(16, 59)),
                new SequenceCondition(2),
                new PeriodCondition(DayOfWeek.THURSDAY, LocalTime.of(10, 0), LocalTime.of(13, 59))
);

 

타이타닉 영화가 비율 할인정책을 사용하고 두 개의 할인조건과 한개의 순서조건이 있는 것을 한눈에 볼 수 있다. 

 

 

 

 상속과 다형성

 

 

 

Movie는 DiscountPolicy 클래스와 연결되어 있다. 코드 수준에서는 DiscountPolicy와 연결되어 있지만 실제 코드가 실행될 때는 구현클래스인 AmountDiscountPolicy나 PercentDiscountPolicy와 연결되어 있다. 

 

여기서 이야기하고 싶은 것은 코드의 의존성과 실행 시점의 의존성이 서로 다를 수 있다는 것이다. 유연하고, 쉽게 재사용할 수 있으며, 확장 가능한 객체지향 설계가 가지는 특징은 코드의 의존성과 실행 시점의 의존성이 다르다.

 

하지만 이 두 시점의 간극이 멀어질 수록 코드를 이해하기가 어려워진다. 반면에 이해는 어렵지만 유연하고 확장 가능해진다. 역시 설계는 트레이드오프의 산물이다. 

 

무조건 유연한 설계도, 무조건 가독성이 좋은 설계도 정답이 아니다. 항상 이 두 가지 기로에서 고민해야 한다. (물론 둘 다 지켜지면 더 좋겠지만 말이다.)

 

 

 

 차이에 의한 프로그래밍

 

부모의 클래스와 다른 부분만 추가해서 새로운 클래스를 쉽고 빠르게 만드는 방법을 '차이에 의한 프로그래밍'이라고 부른다. 

 

차이에 의한 프로그래밍은 중복코드 없이 손쉽게 부모클래스의 기능을 사용하면서 기능을 확장할 수 있다. 이를 가능케하는 것 중 하나가 상속이다. 하지만 상속이 항상 좋은 것은 아니다. 자식 클래스가 부모 클래스에 결합도가 높아지기 때문이다. 이는 뒤에서 살펴본다. 

 

상속이 가치 있는 이유는 부모 클래스의 인터페이스를 자식 클래스에서 전부 사용할 수 있기 때문이다. 이는 클라이언트 입장에서 자신이 메시지를 전달하는 객체가 누구인지 크게 상관하지 않아도 되기 때문에 다형성을 챙겨갈 수 있다. 

 

DiscountPolicy타입에 AmountDiscountPolicy가 할당 가능한 이유는 '업캐스팅'이 일어나기 때문이다. 즉 부모타입으로 타입을 업하는 것이다. 

 

언어차원에서 업캐스팅을 지원한다면 다형성을 지킬 수 있게된다. 다형성은 객체에게 동일한 메시지를 던지지만 실제로 어떤 메서드가 실행될 지는 수신할 객체의 타입에 따라 바뀌는 것을 의미한다. 

 

다형성은 객체지향 프로그램의 컴파일 시간 의존성과 실행 시간 의존성이 다를 수 있다는 사실에 기반으로 한다. 즉 실행 시점에 사용할 메서드를 결정하기 때문에 다양한 형태로 동작 시킬 수 있는 것이다. 이러한 동작을 '지연 바인딩' 혹은 '동적 바인딩'이라고 한다.  

 

 인터페이스와 다형성

 

DiscountPolicy라는 추상 클래스로 다형성을 충족했지만 인터페이스를 통해서도 다형성을 충족시킬 수 있다. 

내부 구현을 공유할 필요없이 순수하게 인터페이스만 공유하도록 하는 것이다. 

DiscountPolicy 내부의 인스턴스의 변수로 있는 DiscountConfition이 바로 그 예다. 

 

 

 

 추상화와 유연성

 

할인 정책과 할인 조건은 구체적인 항목들에서 공통적인 특징을 뽑아서 사용하는 추상화된 개념이다. 이를 프로그래밍 언어 측면에서 보자면 이들이 더 추상적인 이유는 인터페이스를 사용하기 때문이다. 

 

추상화를 사용하면 다음 두 가지 장점이 있다.

1) 요구사항의 정책을 높은 수준에서 서술 가능하다.

2) 설계가 더 유연해진다. 

 

 

추상화된 타입만 보고 관계를 봤을때 핵심적인 흐름을 한 눈에 볼 수 있다.

'영화는 하나의 정책이 있고 여러개의 할인 조건이 있다'

 

이를 통해 세부적인 내용은 무시한 채 협력 흐름을 기술할 수 있다. 재사용 가능한 설계의 기본을 이루는 '디자인 패턴'과 '프레임워크' 모두 추상화를 이용해 상위 정책을 정의하는 객체지향 메커니즘을 활용하고 있다. 

 

바로 이 이점을 확인하기 위해 요구사항 추가로 확인해보자.

 

할인정책이 없는 영화도 있다고 가정해보자. 첫번째 대응은 예외 케이스를 추가하는 것이다.

 

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

 

 

기존에는 할인 정책을 책임지는 쪽이 DiscountPolicy 측에 있었지만 위 코드는 Movie에서 책임을 지고 있기에 지금까지의 협력방식이 깨진다. 항상 예외케이스를 최소화하고 일관성을 유지할 수 있는 방법을 선택해야 한다.

 

이를 위해 NoneDiscountPolicy 클래스를 추가해보자.

 

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

 

이로써 Movie를 수정하지 않고 NoneDiscountPolicy 클래스를 추가하는 것만으로 기능을 확장했다.  

추상화가 유연한 설계를 가능케 하는 이유는 설계가 구체적인 상황에 결합되는 것을 방지하기 때문이다. 

 

DiscountPolicy 역시도 특정 할인 조건에 묶여있지 않은데 이는 추상적이기 때문이다. 이를 '컨텍스트 독립성'이라고 부른다.

 

결론은 간단하다. 유연성이 필요한 곳에 추상화를 사용하자.

 

 

 

 

 상속

 

상속의 가장 큰 문제점은 캡슐화를 위반하는 것이다. 상속을 위해서는 부모 클래스의 내부 구조를 잘 알고 있어야 한다. 

AmountDiscountMovie와 PercentDiscountMovie를 구현하는 개발자는 Movie의 calculateMovieFee 메서드 안에서 추상 메서드인 getDiscountAmount 메서드를 호출한다는 사실을 알고 있어야 한다. 이는 결과적으로 부모 클래스의 변경이 자식클래스의 변경을 초래하게 된다. 

 

두 번째 단점은 설계가 유연하지 않다는 것이다. 상속은 부모 클래스와 자식 클래스의 관계가 컴파일 시점에 결정된다. 따라서 실행 시점에 객체의 종류를 변경하는 것이 불가능하다. 

 

상속을 사용한 설계는 실행 시점에 변경하려면 인스턴스 생성 후 상태를 복사해야 한다. 하지만 위에서 살펴본 방법을 이용하면 실행시점에 할인 정책을 간단하게 변경할 수 있다. 이처럼 인터페이스에 정의된 메시지를 통해서만 코드를 재사용하는 방법을 '합성'이라고 부른다.

 

합성은 상속이 가지는 두 가지 문제점을 모두 해결한다. 인터페이스에 정의된 메시지를 통해서만 재사용하기 때문에 구현을 효과적으로 캡슐화한다. 또한 인스턴스를 교체하는 것이 쉽기 때문에 설계를 유연하게 만든다. 따라서 코드 재사용을 위해서는 상속보다는 합성을 선호하는 것이 더 좋은 방법이다. 

 

그렇다고 상속이 중요하지 않은 것은 아니다. 뒤에서 알아볼 것인데 상속은 코드를 재사용하기 위해 사용하는 것이 아니라 타입계층을 추가하기 위해 사용해야 한다. Money와 DiscountPolicy는 합성 관계로 연결되어 잇고, DiscountPolicy와 AmountDiscountPolicy는 상속 관계로 연결되어 있다. 이처럼 코드를 재사용하는 경우에는 합성 관계를 사용하지만 인터페이스를 재사용하는 경우에는 다형성을 위해 상속과 합성을 함께 사용하는 것이 좋다.