Liskov Substitution Principle을 깊이 있게 설명해 주세요.

Question

Accepted Answer

**Liskov Substitution Principle(LSP)**은 서브타입의 객체가 **프로그램의 정확성을 깨뜨리지 않고** 기반 타입을 대체할 수 있어야 한다고 명시합니다. 코드가 `Base`와 작동한다면, 어떤 `Subclass`와도 작동해야 합니다 — 같은 동작 기대치, 놀라움 없이.

## 전형적인 위반: Square extends Rectangle

```java
class Rectangle {
    protected int w, h;
    void setWidth(int w)  { this.w = w; }
    void setHeight(int h) { this.h = h; }
    int area() { return w * h; }
}

class Square extends Rectangle {       // "정사각형은 직사각형이다"... 겉보기에는
    void setWidth(int w)  { this.w = w; this.h = w; }   // 변을 같게 유지
    void setHeight(int h) { this.w = h; this.h = h; }
}

void resize(Rectangle r) {
    r.setWidth(5);
    r.setHeight(4);
    assert r.area() == 20;   // Rectangle 에서는 성립... Square 에서는 실패 (area=16)
}
```

`Square`는 호출자가 의존하는 *계약을 깨뜨립니다*: 너비와 높이를 독립적으로 설정하는 것 말입니다. 영어의 "is-a" 테스트는 통과하지만 **LSP를 위반**합니다.

## LSP가 실제로 요구하는 것

```text
서브타입은 다음을 해서는 안 됨:
  ✗ 선행 조건 강화  (기반보다 더 많이 요구, 예: 유효한 입력 거부)
  ✗ 후행 조건 약화  (기반보다 적게 약속)
  ✗ 기반이 보장하는 불변식 깨뜨리기
  ✗ 이전에 유효했던 호출에 대해 새 예상치 못한 예외 던지기
서브타입은 다음을 할 수 있음:
  ✓ 선행 조건 약화 (더 많이 수용)   ✓ 후행 조건 강화 (더 많이 약속)
```

이것이 **입력의 반공변성, 출력의 공변성**입니다 — LSP의 형식적 핵심입니다.

## 예시 고치는 법

inheritance를 버리세요: `Square`와 `Rectangle`은 둘 다 `area()`를 가진 `Shape`이지만, 어느 쪽도 다른 쪽이 아닙니다. 순진한 분류가 아니라 동작을 모델링하세요.

## 왜 중요한가

LSP는 polymorphism을 *안전하게* 만드는 것입니다: 그것이 없으면 모든 `if (x instanceof Square)` 검사가 다시 기어들어와 서브타이핑의 의미를 무력화합니다.

이는 inheritance 설계를 어휘가 아니라 **동작 계약**을 중심으로 재구성합니다 — "composition을 선호하라"가 존재하는 진짜 이유는 많은 is-a 관계가 조용히 LSP를 위반하기 때문입니다.