• 바바라 리스코프는 하위 타입을 아래와 같이 정의했다

  여기에서 필요한 것은 다음과 같은 치환 원칙이다. S 타입의 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고,
  T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면,
  S는 T의 하위 타입이다.
  

상속을 사용하도록 가이드하기

• 그림 9.1 License와 파생 클래스는 LSP를 준수한다
• License는 calcFee()라는 메서드를 가지며, Billing 애플리케이션에서 이 메서드를 호출
• License에는 PersonalLicense와 BusinessLicense라는 두 가지 '하위 타입'이 존재
• 이들 두 하위 타입은 서로 다른 알고리즘을 이용해서 라이센스 비용을 계산
• 이 설계는 LSP를 준수하는 데 Billing 애플리케이션의 행위가 License 하위 타입 중 무엇을 사용하는 지에 전혀 의존하지 않기 때문
• 이들 하위 타입은 모두 License 타입을 치환 가능

정사각형/직사각형 문제

• LSP를 위반하는 전형적인 문제로는 유명한 정사각형/직사각형 문제가 있다
• 그림 9.2 악명 높은 정사각형/직사각형 문제
• Square는 Rectangle의 하위 타입으로는 적합하지 않은데, Square의 높이와 너비는 반드시 함께 변경되기 때문
• 혼동이 올 수 있는 코드
• LSP 위반을 막기 위한 유일한 방법은 Retangle이 실제로는 Square인지를 검사하는 메커니즘을 User에 추가
• 하지만 이렇게 하면 User의 행위가 사용하는 타입에 의존하게 되므로, 결국 타입을 서로 치환 할 수 없음

LSP와 아키텍처

• 객체 지향이 혁명처럼 등장한 초창기에는 상속을 사용하도록 가이드 하는 방법 정도로 간주되었다
• 시간이 지나면서 LSP는 인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 변모
• 자바스러운 언어라면 인터페이스 하나와 이를 구현하는 여러 개의 클래스로 구성
• 루비라면 동일한 메서드 시그니처를 공유하는 여러 개의 클래스로 구성