치환의 원칙 , S 타입의 객체 o1 각각에 대응하는 T 타입 객체 o2 가 있고 , T 타입을 이용해서 정의한 모든 프로그램 P 에서 o2 자리에 o1 을 치환하더라도 P 의 행위가 변하지 않는다면 S 는 T 의 하위 타입니다.
( 음… 만약 A 라는 프로그램에서 몬스터들의 자동 전투를 구현한다고 치자. Monster 클래스의 인터페이스를 통해서 Attack() 을 호출을 할 때, 만약 LSP 가 잘 이루어 져있지 않다면 , A 라는 프로그램 내부에서 Monster 가 어떤 몬스터인지 검사를 해야하고 그에 따른 Attack 을 구현해야 할 것 이다. 하지만 LSP 가 잘 구현이 되어 있다면 그냥 Attack() 호출하면 끝이다. )
위 설명처럼 객체가 치환이 되어도 , 프로그램 또는 다른 함수의 행위가 변하지 않는다면 그건 LSP 법칙을 준수했다고 볼 수 있으려나….
객체 지향이 등장한 초창기에 LSP 는 상속을 사용하도록 가이드하는 방법 정도로만 간주되었지만 , 시간이 지나면서 LSP 는 인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 변모해왔다고 한다.
LSP 는 아키텍처 수준까지 확장할 수 있고 , 반드시 확장해야하만 한다고 한다.
항상 치환 가능성을 염두해두자. 그렇지 않으면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다.