LSP : 리스코프 치환 원칙
LSP에 대한 개념은 다음과 같다.
상속 받은 클래스는 기반 클래스를 대체할 수 있어야 한다
LSP로 알려진 바바라 리스코프의 하위 타입은 아래와 같이 정의했다.
여기에서 핋요한 것은 다음과 같은 치환 원칙이다. S 타입의 객체 O1 각각에 대응하는 T 타입 객체 O2가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 O2의 자리에 O1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.
상속을 사용하도록 가이드하기
License라는 클래스가 있다 가정하자. 이는 calcFree() 를 가지며, Billing 애플리케이션이 호출한다.
이 설계는 LSP를 준수하는데, Billing 애플리케이션의 행위가 License 하위 타입 중 어느 것을 사용하는지에 대해 전혀 의존하지 않기 때문이다. 이들 하위 타입은 모두 Lincese 타입을 치환할 수 있다.
LSP와 아키텍처
LSP는 상속을 사용하도록 가이드하는 초창기와는 달리 인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 자리잡게 되었다.
여기에서 말하는 인터페이스는 다양한 형태로 나타난다.
자바와 같은 언어에서는 인터페이스 하나와 이를 구현하는 여러 클래스로 구성된다. 또는 동일한 REST 인터페이스 응답하는 서비스 집단일 수도 있다.
잘 정의된 인터페이스와 그 인터페이스의 구현체끼리의 상호 치환 가능성을 염두에 두어야 사용자들의 사용성에 문제가 없도록 할 수 있다.
결론
LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 하는 원칙이다.
치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다
참조
- 클린 아키텍처(소프트웨어 구조와 설계의 원칙) - 로버트 C. 마틴
- [클린아키텍처] 3부. 설계원칙 LSP
