> For the complete documentation index, see [llms.txt](https://begaonnuri.gitbook.io/me/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://begaonnuri.gitbook.io/me/book/clean-architecture/9.md).

# 9장 LSP: 리스코프 치환 원칙

> S 타입의 객체 o1과 T 타입의 객체 02가 있을 때, 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면 S는 T의 하위 타입이다.

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

Licence라는 인터페이스는 PersonalLicense와 BusinessLicense라는 두 가지 하위 타입을 갖고, 두 하위 타입은 서로 다른 알고리즘을 이용해 라이센스 비용을 계산한다.

이러한 설계는 LSP를 준수한다. License를 사용하는 측에서 어떤 하위타입을 사용하는지에 의존하지 않기 때문이다. 두 하위 타입은 모두 License 타입으로 치환할 수 있다.

## 정사각형/직사각형 문제

정사각형은 직사각형의 하위 타입으로 적합하지 않은데, Rectangle의 높이와 너비는 독립적으로 변경될 수 있지만 정사각형의 높이와 너비는 함께 변경되기 때문이다.

이러한 LSP 위반을 막기 위해 타입을 검사하는 로직을 추가할 수 있지만 클라이언트의 행위가 사각형 타입에 의존하게 된다.

## LSP와 아키텍처

객체 지향 등장 초기에는 LSP가 상속을 사용하도록 가이드하는 방법 정도로 간주되었다. 하지만 시간이 지나면서 LSP는 인터페이스와 구현체에도 적용되는 광범위한 소프트웨어 설계 원칙으로 변했다.

## 결론

LSP는 아키텍처 수준까지 확장할 수 있고 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야할 수 있기 때문이다.