TIL

13 서브클래싱과 서브타이핑

• 상속의 용도
  • 타입 계층 구현
    • 부모 클래스는 일반적인 개념을, 자식 클래스는 특수한 개념을 구현 (일반화와 특수화)
  • 코드 재사용
• 상속 사용의 일차적 목표는 코드 재사용이 아닌 타입 계층 구현이어야 한다.
  • 코드 재사용 목적의 상속은 강결합을 유발해 유연한 설계를 방해한다.
• 객체지향 프로그래밍과 객체 기반 프로그래밍
  • 객체 기반 프로그래밍이란 상태와 행동을 캡슐화한 객체를 조합해서 프로그램을 구성하는 방식
  • 객체 지향 프로그래밍 역시 객체 기반의 한 종류이지만 상속과 다형성을 지원한다는 점이 다르다.

01 타입

개념 관점의 타입

• 개념 관점에서 타입은 우리가 인지하는 사물의 종류를 의미
• 타입의 대상을 인스턴스(instance)라 부른다.
  • 객체라고도 부름
• 타입은 세 가지 요소로 구성된다.
  • 심볼: 타입에 이름을 붙인 것.
  • 내연: 타입의 정의로서 타입에 속하는 객체들이 가지는 공통적 속성이나 행동을 가리킨다.
  • 외연: 타입에 속하는 객체들의 집합

프로그래밍 언어 관점의 타입

• 프로그래밍 언어 관점에서 타입은 연속적인 비트에 의미와 제약을 부여하기 위해 사용
  • 비트 묶음에 의미를 부여하기 위해 정의된 제약과 규칙
• 프로그래밍 언어에서 타입의 목적
  • 타입에 수행할 수 있는 유효한 오퍼레이션 집합을 정의
    • 객체 타입에 따라 적용 가능한 연산자 종류를 제한함으로써 프로그래머의 실수를 막아준다.
  • 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥을 제공
    • 타입에 따라 연산자가 다르게 동작하거나 생성 문맥이 다른 경우가 있다.

객체지향 패러다임 관점의 타입

• 객체지향에서 타입을 정의한다는 것은 객체의 퍼블릭 인터페이스를 정의하는 것과 동일
  • 오퍼레이션 집합 = 객체의 퍼블릭 인터페이스
• 동일한 퍼블릭 인터페이스를 가진다면 동일한 타입으로 분류 가능
  • 객체지향에선 객체가 수신하는 메시지를 기준으로 타입을 분류하기 때문
  • 내부 상태가 다르더라도 동일한 퍼블릭 인터페이스를 공유하면 동일한 타입

02 타입 계층

타입 사이의 포함 관계

• 타입은 객체들의 집합이기에 다른 타입을 포함하는 것이 가능하다.
  • 때문에 동일한 인스턴스가 하나 이상의 타입으로 분류되는 것도 가능하다.
  • 다른 타입을 포함하는 타입은 더 일반화된 의미를 표현할 수 있다.
  • 다른 타입에 포함되는 타입은 더 특수하고 구체적이다.
• 타입 계층에서 더 일반적인 타입을 슈퍼타입(supertype)이라 부른다.
  • 집합이 다른 집합의 모든 멤버를 포함
  • 타입 정의가 좀 더 일반적
• 더 특수한 타입을 서브타입(subtype)이라 부른다.
  • 집합에 포함되는 인스턴스들이 더 큰 집합에 포함된다.
  • 타입 정의가 좀 더 구체적

객체지향 프로그래밍과 타입 계층

• 퍼블릭 인터페이스 관점에서 슈퍼타입과 서브타입
  • 슈퍼타입이란 서브타입이 정의한 퍼블릭 인터페이스를 일반화시켜 더 범용적이고 넢은 의미로 정의한 것
  • 서브타입이란 슈퍼타입이 정의한 퍼블릭 인터페이스를 특수화시켜 더 구체적이고 좁은 의미로 정의한 것
• 서브타입 인스턴스는 슈퍼타입 인스턴스로 간주될 수 있다.
  • 상속과 다형성을 이해하기 위한 출발점

03 서브클래싱과 서브타이핑

언제 상속을 사용해야 하는가

마틴 오더스키는 아래 질문에 모두 “예”라고 답할 수 있는 경우에만 상속을 사용하라고 조언한다.

• 상속 관계가 is-a 관계를 모델링하는가?
  • [자식 클래스는] [부모 클래스다]라고 말해도 이상하지 않은 관계
• 클라이언트 입장에서 부모 클래스 타입으로 자식 클래스를 사용해도 무방한가?
  • 행동 호환성

is-a 관계

• is-a 관계가 생각처럼 직관적이고 명쾌한 것은 아니다.

/**
- ex) 새와 펭귄의 관계
    - 펭귄은 새다.
    - 새는 날 수 있다.
**/

public class Bird {
    public void fly() { ... }
}

public class Penguine extends Bird { 
    // 하지만 펭귄은 날 수 없다.
}

행동 호환성

• 개념적으로 연관성이 있어도 행동에 연관성이 없다면 is-a 관계를 사용하지 말아야 한다.
• 행동 호환 여부를 판단하는 것은 클라이언트의 관점이다.

public void flyBird(Bird bird) {
    // 인자로 전달된 모든 bird는 날 수 있어야 한다.
    bird.fly();
}

• Penguine은 Bird의 자식 클래스이기에 업캐스팅을 허용하지만 펭귄은 날 수 없다.

// 상속 관계를 유지하면서 문제를 해결하는 방법

// 1. `Penguine`에서 `fly` 메서드를 오버라이딩하고 내부 구현을 비워두는 방법
public class Penguine extends Bird {
    @Override
    public void fly() { }
}

// 2. 오버라이딩하고 예외를 던지게 하는 방법
public class Penguine extends Bird {
    @Override
    public void fly() { 
        throw new UnsupportedOperationException();
    }
}

• 1, 2 방법은 클라이언트 관점의 ‘전달된 bird는 날 수 있어야 한다’에 호환되지 않기에 좋은 방법은 아니다.

// 3. 클라이언트에서 bird 타입이 Penguine이 아닌 경우에만 메시지를 전송
public void flyBird(Bird bird) {
    // 인자로 전달된 펭귄 이외의 새는 날 수 있어야 한다.
    if (!(bird instanceof Penguine)) {
        bird.fly();
    }
}

• 3 방법은 또 다른 날 수 없는 상속 계층이 추가된다면 유지보수가 점점 어려워지는 단점이 있다.
  • OCP 위반

클라이언트 기대에 따라 계층 분리하기

• 클라이언트의 기대에 맞게 상속 계층을 분리해야 한다.
• 클라이언트의 관점에서 ‘날 수 있는 새’와 ‘날 수 없는 새’가 있다면 이를 반영하면 된다.

public class Bird { ... }

public class FlyingBird extends Bird { 
    public void fly() { ... }
}

public class Penguine extends Bird { ... }

• 클라이언트가 날 수 있는 새하고만 협력하도록 문맥을 제한

// FlyingBird 타입이 아닌 펭귄이 전달되어 잘못된 행동을 할 위험이 없다
public void flyBird(FlyingBird bird) {
    bird.fly();
}

• 클라이언트에 따라 인터페이스를 분리하는 방법도 있다.
  • Bird는 날 수 있으면서 걸을 수 있어야 하고 Penguine은 걸을 수만 있다고 가정
  • 걷기 행동을 원하는 클라이언트에서너 Walker 타입을 사용하면 Bird와 Penguine 모두를 사용 가능하다.
  • 날기 행동을 원하는 클라이언트에선 Flyer 타입을 사용하면 Bird만 사용하도록 제약할 수 있다.

public Bird implements Flyer, Walker { ... }

public Penguine implements Walker { ... }

• Penguine이 Bird의 코드를 재사용하고 싶다면 상속할 순 있지만 fly 오퍼레이션이 추가되어 버린다.
  • 애초에 재사용을 위한 상속은 위험
• 클라이언트에 따라 인터페이스를 분리하면 변경 영향을 더 세밀하게 제어할 수 있게 된다.
  • 인터페이스 분리 방법의 예시에서 ‘날 수 있다’는 행동에 대해 변경이 필요하다면 Flyer에 의존하는 Bird는 영향을 받지만 Penguine과 ‘걸을 수 있다’는 행동에 의존하는 클라이언트들은 영향을 받지 않는다.
  • 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

서브 클래싱과 서브 타이핑

• 서브클래싱(subclassing)
  • 코드 재사용을 목적으로 상속을 사용하는 경우
  • 자식과 부모의 행동이 호환되지 않아 자식이 부모를 대체할 수 없다.
  • ‘구현 상속’ 또는 ‘클래스 상속’이라 부른다.
• 서브타이핑(subtyping)
  • 타입 계층을 구성하기 위해 상속을 사용하는 경우
  • 자식과 부모의 행동이 호환되기에 자식이 부모를 대체 가능
  • ‘인터페이스 상속’이라 부른다.
• 슈퍼타입과 서브타입 사이 가장 중요한 것은 퍼블릭 인터페이스
  • 서브타입은 슈퍼타입을 요구하는 모든 곳에서 대체 가능해야 한다.
  • 서브타입은 최소 슈퍼타입의 퍼블릭 인처페이스와 동일하거나 더 많은 오퍼레이션을 포함해야 한다.
  • ‘행동 호환성’을 만족시켜야 한다.

04 리스코프 치환 원칙

• 리스코프 치환 원칙 (Liskov Substitution Principle, LSP)
  • 서브타입은 그것 기반 타입에 대해 대체 가능해야 한다
  • 클라이언트가 인터페이스를 통해 차이점을 인식하지 못한 채 서브클래스를 사용할 수 있어야 한다.
• LSP를 위반한다는 것은 클라이언트가 부모에게 기대하는 행동을 자식에게 기대할 수 없는 경우이다.
  • Stack과 Vector
  • Penguine과 Bird

클라이언트와 대체 가능성

• LSP는 자식이 부모를 대체하기 위해서 부모에 대한 클라이어트의 가정을 준수해야 한다는 것을 강조한다.
  • “클라이언트와 격리한 채로 본 모델은 의미 있게 검증하는 것이 불가능하다.”
  • 어떤 모델의 유효성을 클라이언트 관점에서 검증 가능하다는 것
• 행동 호환성과 LSP에서 중요한 것은 대체 가능성을 결정하는 것은 클라이언트라는 것이다.

리스코프 치환 원칙은 유연한 설계의 기반이다

• LSP는 클라이언트가 어떤 자식과 협력해도 안정적일 수 있는 가이드라인을 제공한다.
• LSP를 따르는 설계는 유연성과 확장성이 높다.
• 자식 클래스가 부모 클래스를 클라이언트 관점에서 대체 가능하다면 확장을 위해 코드를 수정할 필요가 없어진다.

타입 계층과 리스코프 치환 원칙

• 클래스 상속은 타입 계층을 구현할 수 있는 다양한 방법 중 하나일 뿐이다.
  • 자바의 인터페이스 또는 스칼라의 트레이트 등으로도 서브타이핑 관계를 구현할 수 있다.
• 코드 재사용 목적으로 클래스 상속을 남용하면 리스코프 치환 원칙을 위반하게 된다.

05 계약에 의한 설계와 서브타이핑

• 계약에 의한 설계
  • 클라이언트와 서버 사이의 협력을 ‘의무’와 ‘이익’으로 구성된 계약 관점으로 표현하는 것
  • 구성 요소
    • 사전 조건: 메서드 클라이언트가 메서드 실행 전에 만족시켜야 하는
    • 사후 조건: 메서드 실행 후에 서버가 클라이언트에게 보장해야 하는
    • 클래스 불변식: 메서드 실행 전후로 인스턴스가 만족시켜야 하는
  • 서브타입이 LSP를 만족시키기 위해선 클라이언트와 슈퍼타입 간 체결된 ‘계약’을 준수해야 한다.
• Movie와 DiscountPolicy 간의 계약
  • 사전 조건
    • 전달되는 Screening이 null이 아니여야 한다.
    • 영화 시작 시간이 아직 지나지 않아야 한다.
  • 사후 조건
    • 반환되는 Money가 null이 아니여야 한다.

public class Movie {
    // ...
    public Money calculateMovieFee(Screening screening) {
        if (screening == null ||
                screening.getStartTime().isBefore(LocalDateTime.now())) {
            throw new InvalidScreeningException();
        }

        return fee.minus(discountPolicy.calculateDiscountAmount(screening));
    }
// ...
}

public abstract class DiscountPolicy {
    // ...
    public Money calculateDiscountAmount(Screening screening) {
        checkPrecondition(screening); // 사전조건 체크
        Money amount = Money.ZERO;
        for(DiscountCondition each : conditions) {
            if (each.isSatisfiedBy(screening)) {
                amount = getDiscountAmount(screening);
                checkPostcondition(amount);
                return amount;
            }
        }
        amount = screening.getMovieFee();
        checkPostcondition(amount); // 사후조건 체크
        return amount;
    }
}

서브타입과 계약

• 계약 관점에서 상속의 큰 문제는 자식이 부모 메서드를 오버라이딩할 수 있다는 것
  • 서브타입에 더 강력한 사전조건을 정의할 수 없다.
  • 서브타입에 슈퍼타입과 같거나 더 약한 사전조건을 정의할 수 있다.
  • 서브타입에 슈퍼타입과 같거나 더 강한 사후조건을 정의할 수 있다.
  • 서브타입에 더 약한 사후조건을 정의할 수 없다.
• 즉 어떤 타입이 슈퍼타입의 서브타입이 되려면
  • 더 강한 사전조건을 정의할 수 없다.
  • 더 약한 사후조건을 정의할 수 없다.