🌈 Chapter 13: 서브클래싱과 서브타이핑

• 상속의 첫 번째 용도는 타입 계층을 구현하는 것이다. 타입 계층의 관점에서 부모 클래스는 자식 클래스의 일반화이고 자식 클래스는 부모 클래스의 특수화다.
• 상속의 두 번째 용도는 코드 재사용이다. 상속을 사용하면 점진적으로 애플리케이션의 기능을 확장할 수 있다. 하지만 재사용을 위해 상속을 사용할 경우 부모 클래스와 자식 클래스가 강하게 결합되기 때문에 변경하기 어려운 코드를 얻게 될 확률이 높다.
• 상속을 사용하는 일차적인 목표는 코드 재사용이 아니라 타입 계층을 구현하는 것이어야 한다. 타입 계층을 목표로 상속을 사용하면 다형적으로 동작하는 객체들의 관계에 기반해 확장 가능하고 유연한 설계를 얻을 수 있게 된다.
• 타입 사이의 관계를 고려하지 않은 채 단순히 코드를 재사용하기 위해 상속을 사용해서는 안 된다.

📚 타입

🎈 개념 관점의 타입

• 개념 관점에서 타입이란 우리가 인지하는 세상의 사물의 종류를 의미한다. 다시 말해 우리가 인식하는 객체들에 적용하는 개념이나 아이디어를 가리켜 타입이라고 부른다. 타입은 사물을 분류하기 위한 틀로 사용된다.
• 예를 들어, 자바, 루비, 자바스크립트, C를 프로그래밍 언어라고 부를 때 이것들을 프로그래밍 언어라는 타입으로 분류하고 있는 것이다.
• 어떤 대상이 타입으로 분류될 때 그 대상을 타입의 인스턴스라고 부른다. (자바, 루비, 자바스크립트는 프로그래밍 언어의 인스턴스다.) 일반적으로 타입의 인스턴스를 객체라고 부른다.
• 심볼(symbol)이란 타입에 이름을 붙인 것이다. (프로그래밍 언어가 타입의 심볼에 해당한다.)
• 내연(intension)이란 타입의 정의로서 타입에 속하는 객체들이 가지는 공통적인 속성이나 행동을 가리킨다. (프로그래밍 언어의 정의인 컴퓨터에게 특정한 작업을 지시하기 위한 어휘와 문법적 규칙의 집합)
• 외연(extension)이란 타입에 속하는 객체들의 집합이다. (자바, 루비, 자바스크립트, C)

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

• 프로그래밍 언어의 관점에서 타입은 비트 묶음에 의미를 부여하기 위해 정의된 제약과 규칙을 가리킨다.
• 프로그래밍 언어에서 타입은 두 가지 목적을 위해 사용된다.
  • 타입에 수행될 수 있는 유효한 오퍼레이션의 집합을 정의한다.
  • 타입에 수행되는 오퍼레이션에 대해 미리 약속된 문맥을 제공한다.
• 정리하면 타입은 적용 가능한 오퍼레이션의 종류와 의미를 정의함으로써 코드의 의미를 명확하게 전달하고 개발자의 실수를 방지하기 위해 사용된다.

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

• 개념 관점에서 타입이란 공통의 특징을 공유하는 대상들의 분류다.
• 프로그래밍 언어 관점에서 타입이란 동일한 오퍼레이션을 적용할 수 있는 인스턴스들의 집합이다.

• 프로그래밍 언어의 관점에서 호출 가능한 오퍼레이션의 집합을 정의한다. 객체지향 프로그래밍에서 오퍼레이션은 객체가 수신할 수 있는 메시지를 의미한다. 따라서 객체의 타입이란 객체가 수신할 수 있는 메시지의 종류를 정의하는 것이다.
• 객체가 수신할 수 있는 메시지의 집합을 가리키는 용어로 퍼블릭 인터페이스가 그것이다. 즉, 객체지향 프로그래밍에서 타입을 정의하는 것은 객체의 퍼블릭 인터페이스를 정의하는 것과 동일하다.
• 객체지향에서 객체가 수신할 수 있는 메시지를 기준으로 타입을 분류하기 때문에 동일한 퍼블릭 인터페이스를 가지는 객체들은 동일한 타입으로 분류할 수 있다.

📚 타입 계층

🎈 타입 사이의 포함관계

• 타입은 객체들의 집합이기 때문에 다른 타입을 포함하는 것이 가능하다.
• 타입 안에 포함된 객체들을 좀 더 상세한 기준으로 묶어 새로운 타입을 정의하면 이 새로운 타입은 자연스럽게 기존 타입의 부분집합이 된다.
• 예를 들어 자바, 루비, 자바스크립트 C는 프로그래밍 언어 타입의 인스턴스이므로 프로그래밍 언어 집합의 원소로 표현할 수 있다. 이 집합의 원소를 더 상세하게 분류할 수 있다. 자바, 루비, 자바스크립트는 객체지향 언어고 C는 절차적 언어로 분류할 수 있다. 더 나아가 자바와 루비는 클래스 기반 언어로, 자바스크립트는 프로토타입 기반 언어로 분류할 수 있다.
• 여기서 자바는 프로그래밍 언어인 동시에 객체지향 언어에 속하며 더 세부적으로 클래스 기반 언어 타입에 속하게 되는 것이다.
• 다른 타입을 포함하는 타입은 포함하는 타입보다 좀 더 일반화된 의미를 표현할 수 있다. 반면 포함되는 타입은 좀 더 특수하고 구체적이다.
• 다른 타입을 포함하는 타입은 포함되는 타입보다 더 많은 인스턴스를 가진다.
• 다시 말해서 포함되는 타입은 외연 관점에서는 더 크고 내연 관점에서는 더 일반적이다. 이와 반대로 포함되는 타입은 외연 관점에서는 더 작고 내연 관점에서는 더 특수하다. 이것은 포함 관계로 연결된 타입 사이에 개념적으로 일반화와 특수화 관계가 존재한다는 것을 의미한다.
• 타입 계층을 구성하는 두 타입 간의 관점에서 더 일반적인 타입을 슈퍼타입(supertype)이라고 부르고 더 특수한 타입을 서브타입(subtype)이라고 부른다.
• 객체의 정의를 의미하는 내연 관점에서 일반화란 어떤 타입의 정의를 좀 더 보편적이고 추상적으로 만드는 과정을 의미한다. 반대로 특수화란 어떤 타입의 정의를 좀 더 구체적이고 문맥 종속적으로 만드는 과정을 의미한다.
• 집합을 의미하는 외연의 관점에서 일반적인 타입의 인스턴스 집합은 특수한 타입의 인스턴스 집합을 포함하는 슈퍼셋이다. 반대로 특수한 타입의 인스턴스 집합은 일반적인 타입의 인스턴스 집합에 포함된 서브셋이다. 따라서 특수한 타입에 속한 인스턴스는 동시에 더 일반적인 타입의 인스턴스이기도 하다.
• 일반화는 다른 타입을 완전히 포함하거나 내포하는 타입을 식별하는 행위 또는 그 행위의 결과를 가리킨다.
• 특수화는 다른 타입 안에 전체적으로 포함되거나 완전히 내포되는 타입을 식별하는 행위 또는 그 행위의 결과를 가리킨다.
• 내연과 외연 관점에서 서브타입과 슈퍼타입을 다음과 같이 정의할 수 있다.
  • 슈퍼타입은 다음과 같은 특징을 가지는 타입을 가리킨다.
    • 집합이 다른 집합의 모든 멤버를 포함한다.
    • 타입 정의가 다른 타입보다 좀 더 일반적이다.
  • 서브타입은 다음과 같은 특징을 가지는 타입을 가리킨다.
    • 집합에 포함되는 인스턴스들이 더 큰 집합에 포함된다.
    • 타입 정의가 다른 타입보다 좀 더 구체적이다.

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

• 객체의 타입을 결정하는 것은 퍼블릭 인터페이스다.
• 일반적인 타입이란 비교하려는 타입에 속한 객체들의 퍼블릭 인터페이스보다 더 일반적인 퍼블릭 인터페이스를 가지는 객체들의 타입을 의미한다.
• 특수한 타입이란 비교하려는 타입에 속한 객체들의 퍼블릭 인터페이스보다 더 특수한 퍼블릭 인터페이스를 가지는 객체들의 타입을 의미한다.
• 슈퍼타입이란 서브타입이 정의한 퍼블릭 인터페이스를 일반화시켜 상대적으로 범용적이고 넓은 의미로 정의한 것이다.
• 서브타입이란 슈퍼타입이 정의한 퍼블릭 인터페이스를 특수화시켜 상대적으로 구체적이고 좁은 의미로 정의한 것이다.
• 서브타입의 인스턴스는 슈퍼타입의 인스턴스로 간주될 수 있다.

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

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

• 다음 두 질문에 모두 예라고 답할 수 있는 경우에만 상속을 사용해야 한다.
  • 상속 관계가 is-a 관계를 모델링하는가? (자식 클래스는 부모클래스다.)
  • 클라이언트 입장에서 부모 클래스의 타입으로 자식클래스를 사용해도 무방한가? (상속 계층을 사용하는 클라이언트의 입장에서 부모 클래스와 자식 클래스의 차이점을 몰라야 한다. 이 둘 사이의 행동 호환성이라 부른다.)

🎈 is-a 관계

• 어떤 타입 S가 다른 타입 T의 일종이라면 당연히 타입 S는 타입 T다라고 말할 수 있어야 한다. (객체지향 언어는 프로그래밍 언어다.)
• 하지만 is-a관계가 직관적이고 명쾌한 것은 아니다.
  • 펭귄은 새다.
  • 새는 날 수 있다.

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

public class Penguin extends Bird { // 펭귄은 날 수 없다.
  // ...
}

• 이 예는 어휘적인 정의가 아니라 기대되는 행동에 따라 타입 계층을 구성해야 한다는 사실을 잘 보여준다.
• 따라서 타입 계층의 의미는 행동이라는 문맥에 따라 달라질 수 있다. 그에 따라 올바른 타입 계층이라는 의미 역시 문맥에 따라 달라질 수 있다. 따라서 슈퍼타입과 서브타입 관계에서는 is-a보다 행동 호환성이 더 중요하다.

🎈 행동 호환성

• 타입의 이름 사이에 개념적으로 어떤 연관성이 있다고 하더라도 행동에 연관성이 없다면 is-a관계를 사용하지 말아야 한다.
• 두 타입 사이에 행동이 호환될 경우에만 타입 계층으로 묶어야 한다. 행동의 호환 여부를 판단하는 기준은 클라이언트의 관점이다. 클라이언트가 두 타입이 동일하게 행동할 것이라고 기대한다면 두 타입을 타입 계층으로 묶을 수 있다. 타입 계층을 이해하기 위해서는 그 타입 계층이 사용될 문맥을 이해하는 것이 중요하다.
• 다음과 같이 클라이언트가 날 수 있는 새만을 원한다고 가정해본다.

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

• Penguin은 클라이언트의 기대를 저버리기 때문에 Bird의 서브타입이 아니다. 따라서 이 둘을 상속 관꼐로 연결한 위 설계는 수정돼야 한다. 상속 관계를 유지하면서 문제를 해결하기 위해 시도해 볼 수 있는 세 가지 방법이 있다.
• 첫 번째 방법은 Penguin의 fly 메서드를 오버라이딩해서 내부 구현을 비워두는 것이다.

public class Penguin extends Bird {
  // ...
  @Override
  public void fly() {}
}

• 하지만 이 방법은 어떤 행동도 수행하지 않기 때문에 모든 bird가 날 수 있다는 클라이언트의 기대를 만족시키지 못한다. 따라서 올바른 설계가 아니다.
• 두 번째 방법은 Penguin의 fly 메서드를 오버라이딩한 후 예외를 던진다.

public class Penguin extends Bird {
  // ...
  @Override
  public void fly() {
    throw new UnsupportedOperationException();
  } 
}

• 하지만 이 경우에는 flyBird 메서드에 전달되는 인자를 타입에 따라 메서드가 실패하거나 성공하게 된다.
• 세 번째 방법은 flyBird 메서드를 수정해서 인자로 전달된 bird의 타입이 Penguin이 아닐 경우에만 fly 메시지를 전송하도록 한다.

public void flyBird(Bird bird) {
  // 인자로 전달된 모든 bird가 Penguin의 인스턴스가 아닐 경우에만
  // fly() 메시지를 전송한다.
  if (!(bird instanceof Penguin)) {
    bird.fly();
  }
}

• 하지만 이 경우에는 만약 Penguin 이외에 날 수 없는 또 다른 새가 상속 계층에 추가된다면 새로운 타입을 체크하는 코드를 추가해야 한다. 개방-폐쇄 원칙을 위반한다.

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

• 문제를 해결할 수 있는 방법은 클라이언트의 기대에 맞게 상속 계층을 분리하는 것이다.
• 날 수 있는 새와 날 수 없는 새를 명확하게 구분할 수 있게 상속 계층을 분리하면 서로 다른 요구사항을 가진 클라이언트를 만족시킬 수 있다.

public class Bird {
  // ...
}

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

public class Penguin extends Bird {
  // ...
}

• 이제 flyBird 메서드는 FlyingBird 타입을 이용해 날 수 있는 새만 인자로 전달돼야 한다는 사실을 코드에 명시할 수 있다.

public void flyBird(FlyingBird bird) {
  bird.fly();
}

• 이 문제를 해결하는 다른 방법은 클라이언트에 따라 인터페이스를 분리하는 것이다. 인터페이스는 클라이언트가 기대하는 바에 따라 분리돼야 한다. 클라이언트에 따라 인터페이스를 분리하면 변경에 대한 영향을 더 세밀하게 제어할 수 있게 된다.
• 인터페이스를 클라이언트의 기대에 따라 분리함으로써 변경에 의해 영향을 제어하는 설계 원칙을 인터페이스 분리 원칙(ISP)이라고 부른다.

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

• 상속의 두 가지 목적은 코드 재사요을 위해서고, 다른 하나는 타입 계층을 구성하기 위해서다.
• 상속을 사용하는 두 가지 목적에 특별한 이름을 붙였는데 서브클래싱과 서브타이핑이 그것이다.

서브클래싱(subclassing)

• 다른 클래스의 코드를 재사용할 목적으로 상속을 사용하는 경우를 가리킨다. 자식 클래스와 부모 클래스의 해동이 호환되지 않기 때문에 자식 클래스의 인스턴스가 부모 클래스의 인스턴스를 대체할 수 없다.
• 서브클래싱을 구현 상속또는 클래스 상속이라고 부른다.

서브타이핑(subtyping)

• 타입 계층을 구성하기 위해 상속을 사용하는 경우를 가리킨다. 자식 클래스와 부모 클래스의 행동이 호환되기 때문에 자식 클래스의 인스턴스가 부모 클래스의 인스턴스를 대체할 수 있다. 이때 부모 클래스는 자식 클래스의 슈퍼타입이 되고 자식 클래스는 부모 클래스의 서브타입이 된다.
• 서브타이핑을 인터페이스 상속이라고 부르기도 한다.

• 서브클래싱과 서브타이핑을 나누는 기준은 상속을 사용하는 목적이다.
• 서브타이핑 관계가 유지되기 위해서는 서브타입이 슈퍼타입이 하는 모든 행동을 동일하게 할 수 있어야 한다. 즉, 어떤 타입이 다른 타입의 서브타입이 되기 위해서는 행동 호환성을 만족시켜야 한다.
• 자식 클래스와 부모 클래스 사이의 행동 호환성은 부모 클래스에 대한 자식 클래스의 대체 가능성을 포함한다.

📚 리스코프 치환 원칙

• 리스코프 치환 원칙(LSP)는 서브타입은 그것의 기반 타입에 대해 대체 가능해야한다는 것으로 클라이언트가 차이점을 인식하지 못한 채 기반 클래스의 인터페이스를 통해 서브클래스를 사용할 수 있어야 한다.
• 리스코프 치환 원칙에 따르면 자식 클래스가 부모 클래스와 행동 호환성을 유지함으로써 부모 클래스를 대체할 수 있도록 구현된 상속 관계만을 서브타이핑이라고 불러야 한다.
• 이번 예제는 정사각형은 직사각형이다라는 이야기이다. 하지만 정사각형은 직사각형이 아닐 수 있다. 이 상속 관계는 리스코프 치환 원칙을 위반하는 고전적인 사례 중 하나다.
• 아래는 직사각형을 구현한 Rectangle이다.

public class Rectangle {
  private int x, y, width, height;

  public Rectangle(int x, int y, int width, int height) {
    this.x = x; // 왼쪽 상단 모서리 위치 (x, y)
    this.y = y;
    this.width = width; // 너비
    this.height = height; // 높이
  }

  public int getWidth() {
    return width;
  }

  public void setWidth(int width) {
    this.width = width;
  }

  public int getHeight() {
    return height;
  }

  public void setHeight(int height) {
    this.height = height;
  }

  public int getArea() {
    return width * height;
  }
}

• 정사각형은 직사각형의 특수한 경우이고 직사각형은 정사각형의 일반적인 경우이기 때문에 정사각형과 직사각형의 사이에 어휘적으로 is-a관계가 성립한다.
• 정사각형은 너비와 높이가 동일해야 한다.

public class Square extends Rectangle {
  public Square(int x, int y, int size) {
    super(x, y, size, size);
  }

  @Override
  public void setWidth(int width) {
    super.setWidth(width);
    super.setHeight(width);
  }

  @Override
  public void setHeight(int height) {
    super.setWidth(height);
    super.setHeight(height);
  }
}

• Square는 Rectangle의 자식 클래스이기 때문에 Rectangle이 사용되는 모든 곳에서 Rectangle로 업캐스팅될 수 있다. 문제는 Rectangle과 협력하는 클라이언트는 직사각형 너비와 높이가 다르다고 가졍할때 발생한다. 따라서 아래 코드처럼 직사각형의 너비와 높이를 서로 다르게 설정하도록 프로그래밍할 것이다.

public void resize(Rectangle rectangle, int width, int height) {
  rectangle.setWidth(width);
  rectangle.setHeight(height);
  assert rectangle.getWidth() === width && rectangle.getHeight() === height;
}

• 그러나 resize 메서드의 인자로 Square를 전달한다고 가정해보면, 더 나중에 설정된 height의 값으로 같아지게 된다. 따라서 다음과 같이 width와 height값을 다르게 설정할 경우 메서드 실행에 실패하고 말 것이다.

Square square = new Square(10, 10, 10);
resize.(square, 50, 100);

• resize 메서드의 관점ㄴ에서 Rectangle대신 Square를 사용할 수 없기 때문에 Square는 Rectangle이 아니다. 두 클래스는 구현을 재사용하고 있을 뿐이기 때문에 리스코프 치환 원칙을 위반한다. 따라서 서브타이핑 관계가 아니라 서브클래싱 관계다.

🎈 클라이언트와 대체 가능성

• 클라이언트 입장에서 정사각형을 추상화한 Square는 직사각형을 추상화한 Rectangle과 동일하지 않다.
• 리스코프 치환 원칙은 자식 클래스가 부모 클래스를 대체하기 위해서는 부모 클래스에 대한 클라이언트의 가정을 준수해야 한다는 것을 강조한다.
• 리스코프 치환 원칙은 상속 관계에 있는 두 클래스 사이의 관계를 클라이언트와 떨어트려 놓고 판단하지 말아야 한다. 상속 관계는 클라이언트의 관점에서 자식 클래스와 부모 클래스를 대체할 수 있을 때만 올바르다.
• 대체 가능성을 결정하는 것은 클라이언트다.

🎈 is-a 관계 다시 살펴보기

• 클라이언트 관점에서 자식 클래스의 행동이 부모 클래스의 행동과 호환되지 않고 그로 인해 대체가 불가능하다면 어휘적으로 is-a라고 말할 수 있다고 하더라도 그 관계를 is-a 관계라고 할 수 없다.
• is-a는 클라이언트 관점에서 is-a일 때만 참이다. 클라이언트가 이 둘을 동일하게 취급할 수 있을 때만 그렇다. (클라이언트 입장에서 정사각형은 직사각형인가? 클라이언트 입장에서 펭귄은 새인가?)
• is-a 관계는 객체지향에서 중요한 것은 객체의 속성이 아니라 객체의 행동이라는 점을 강조한다.
• 슈퍼타입과 서브타입이 클라이언트 입장에서 행동이 호환된다면 두 타입을 is-a로 연결해 문장을 만들어도 어색하지 않은 단어로 타입의 이름을 정하라는 것이다.
• 결론적으로 상속이 서브타이핑을 위해 사용될 경우에만 is-a관계다.

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

• 새로운 자식 클래스를 추가하더라도 클라이언트 입장에서 동일하게 행동하기만 한다면 클라이언트를 수정하지 않고도 상속 계층을 확장할 수 있다.
• 리스코프 치환 원칙을 따르는 설계는 유연할뿐만 아니라 확장성이 높다.
• 리스코프 치환 원칙은 개방-폐쇄 원칙을 만족하는 설계를 위한 전제 조건이다.

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

• 구현 방법과 무관하게 클라이언트의 관점에서 슈퍼타입에 대해 기대하는 모든 것이 서브타입에게도 적용돼야 한다는 것이다.

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

• 클라이언트와 서버 사이의 협력을 의무와 이익으로 구성된 계약의 관점에서 표현하는 것을 계약에 의한 설계(DBC)라고 부른다.
• 계약에 의한 설계는 클라이언트가 정상적으로 메서드를 실행하기 위해 만족시켜야 하는 사전조건과 메서드가 실행된 후에 서버가 클라이언트에게 보장해야하는 사후조건, 메서드 실행 전과 실행 후에 인스턴스가 만족시켜야 하는 클래스 불변식의 세 가지 요소로 구성된다.
• 계약에 의한 설계를 사용하면 리스코프 치환 원칙이 강제하는 조건을 계약의 개념을 이용해 좀 더 명확하게 설명할 수 있다.

서브타입이 리스코프 치환 원칙을 만족시키기 위해서는 클라이언트와 슈퍼타입 간에 체결된 계약을 준수해야 한다.

• 계약에 의한 설계에 따르면 협력하는 클라이언트와 슈퍼타입의 인스턴스 사이에는 어떤 계약이 맺어져 있다. 클라이언트와 슈퍼타입은 이 계약을 준수할 때만 정상적으로 협력한다. 클라이언트 입장에서 서브타입은 슈퍼타입의 한 종류여야 하는 것이다.

예제 생략.

🎈 서브타입과 계약

• 계약의 관점에서 상속이 초래하는 가장 큰 문제는 자식 클래스가 부모 클래스의 메서드를 오버라이딩할 수 있다는 것이다.
• 예를 들어서 DiscountPolicy를 상속받는 BrokenDiscountPolicy 클래스는 calculateDiscountAmount 메서드를 오버라이딩한 후 여기에 새로운 사전조건을 추가한다. 이 새로운 사전조건은 종료 시간이 자정을 넘는 영화를 예매할 수 없다는 것이다. 따라서 DiscountPolicy보다 더 강화된 사전조건을 정의한다.

public class BrokenDiscountPolicy extends DiscountPolicy {
  public BrokenDiscountPolicy(DiscountCondition ... conditions) {
    super(conditions);
  }

  @Override
  public Money calculateDiscountAmount(Screening screening) {
    checkPrecondition(screening); // 기존의 사전조건
    checkStrongPrecondition(screening); // 더 강력한 사전조건

    Money amount = screening.getMovieFee();;
    checkPostcondition(amount); // 기존의 사후조건
    return amount;
  }

  // ...
}

• BrokenDiscountPolicy 클래스가 DiscountPolicy 클래스의 자식 클래스이기 때문에 컴파일러는 아무런 제약 없이 업캐스팅을 허용한다. 문제는 Movie는 오직 DiscountPolicy의 사전조건만 알고 있다는 점이다. 그렇기 때문에 BrokenDiscountPolicy의 추가한 사전조건은 이를 허용하지 않기 때문에 협력은 실패하고 만다. 다시말해서 클라이언트 관점에서 DiscountPolicy를 대체할 수 없기 때문에 서브타입이 아니다.
• 따라서 자식 클래스가 부모 클래스의 서브타입이 되기 위해서는 다음 조건을 만족시켜야 한다.

📌 서브타입에 더 강력한 사전조건을 정의할 수 없다.

• 그 반대로 사전조건을 제거해서 약화시킨다면 어떻게 될까?

public class BrokenDiscountPolicy extends DiscountPolicy {
  // ...
    @Override
  public Money calculateDiscountAmount(Screening screening) {
    // checkPrecondition(screening); // 기존의 사전조건 제거

    Money amount = screening.getMovieFee();;
    checkPostcondition(amount); // 기존의 사후조건
    return amount;
  }
  // ...
}

• BrokenDiscountPolicy는 Screening에 대한 사전조건을 체크하지 않았지만 Movie는 DiscountPolicy가 정의한 사전조건을 만족시키기 위해 null이 아니며 현재 시간 이후에 시작하는 Screening을 전달하는 것을 보장하고 있다. 따라서 이 경우에는 아무런 문제도 발생하지 않는다.

📌 서브타입에 슈퍼타입과 같거나 더 약한 사전조건을 정의할 수 있다.

• 만약 사후조건을 강화한다면 어떻게 될까?

public class BrokenDiscountPolicy extends DiscountPolicy {
  // ...
    @Override
  public Money calculateDiscountAmount(Screening screening) {
    checkPrecondition(screening); // 기존의 사전조건

    Money amount = screening.getMovieFee();;
    checkPostcondition(amount); // 기존의 사후조건
    checkStrongerPostcondition(amount); // 더 강력한 사후조건
    return amount;
  }
  // ...
}

• Movie는 DiscountPolicy의 사후조건만 알고 있다. Movie는 최소한 0보다 큰 금액을 반환하기만 하면 협력이 정상적으로 수행됐다고 가정한다. 따라서 BrokenDiscountPolicy가 1000원 이상의 금액을 반환하는 것은 계약을 위반하지 않는다. 따라서 다음과 같은 사실을 알 수 있다.

📌 서브타입에 슈퍼타입과 같거나 더 강한 사후조건을 정의할 수 있다.

• 사후조건을 약하게 정의하면 어떻게 될까?

public class BrokenDiscountPolicy extends DiscountPolicy {
  // ...
    @Override
  public Money calculateDiscountAmount(Screening screening) {
    checkPrecondition(screening); // 기존의 사전조건

    Money amount = screening.getMovieFee();;
    // checkPostcondition(amount); // 기존의 사후조건 제거
    checkWeakerPostcondition(amount); // 더 약한 사후조건
    return amount;
  }
  // ...
}

• 이 경우에는 원하지 않았던 결과로 이어지고 만다.

📌 서브타입에 더 약한 사후조건을 정의할 수 없다.

• 계약에 의한 설계는 클라이언트 관점에서 대체 가능성을 계약으로 설명할 수 있다는 사실을 잘 보여준다. 따라서 서브타이핑을 위해 상속을 사용하고 있다면 부모 클래스가 클라이언트와 맺고 있는 계약에 관해 깊이 있게 고민해야 한다.