자료형S가 자료형T의 하위형이라면 필요한 프로그램의 속성(정확성, 수행하는 업무 등)의 변경 없이 자료형T의 객체를 자료형S의 객체로 교체(치환)할 수 있어야 한다는 원칙이다.
상속을 사용하도록 가이드하기
Biling라는 애플리케이션에서는 단순히 calcFee()라는 메서드를 호출한다고 하자.
Biling의 행위가 License의 하위 타입 중 뭘 사용하는지에 대해 의존하지 않기 때문에, LSP에 만족한다고 볼 수 있다. (하위타입인 두 타입이 License를 치환해도 문제 없기 때문이다.
정사각형/직사각형 문제
LSP를 위반하는 사례를 알아보자
아래 그림에서 Square은 Rectangle의 하위타입에 적합하지 않다.
Rectangle은 너비와 높이가 독립적으로 변하지만, Square은 함께 변경되기 때문이다.
코드로 보면 좀 더 명확하다.
Rectangle r = ...
r.setW(5);
r.setH(2);
assert(r.area() == 10);...에 해당하는 부분에 Square을 넣는다면, assert문은 실패하게 될 것이다.
LSP와 아키텍처
아키텍처 관점에서 LSP를 이해하려면, 그것이 위반되었을때의 상황을 관찰하는 것이다.
LSP 위배 사례
아버지 나= new 딸();
아버지의 하위 타입인 딸로 생성했더니, 아버지의 역할도 하고 있다. 이는 말이 안되는 소리다.
나는 아버지형 객체 참조 변수기 때문에, 아버지 객체가 가진 행위를 할 수 있어야 하는데, 매우 이상하다.
조류 뽀로로 = new 펭귄();
뽀로로는 펭귄타입으로 생성했다. 뽀로로는 펭귄이며, 조류의 행위도 할 수 있기 때문에, LSP를 만족한다고 볼 수 있다.
결론
LSP는 아키텍처 수준까지 확장되어야만 한다. LSP가 위배되면, 아키텍처가 상당히 오염될 수 있다.
