9장. LSP: 리스코프 치환 원칙(Liskov Substitution Principle)

9장. LSP: 리스코프 치환 원칙(Liskov Substitution Principle)

1988년 바바라 리스코프가 정의한 하위타입에 관한 원칙.

상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성요소는 반드시 서로 치환 가능해야 한다는 계약을 반드시 지켜야 한다.

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

위 설계는 LSP를 준수한다. Billing 애플리케이션의 행위가 License 하위 타입 중 무엇을 사용하는지에 전혀 의존하지 않기 때문이다. 하위 타입은 모두 License로 치환할 수 있다.

 

정사각형/직사각형 문제

Square는 Reactangle의 하위 타입으로 적합하지 않다.

User는 대화하고 있는 상대가 Rectangle이라고 생각하므로 혼동이 생길 수 있다.

이 상태에서 LSP 위반을 막기 위한 방법은 IF 문 등을 이용해서 Rectangle이 실제로 Square인지를 검사하는 메커니즘을 User에 추가하는 것이다.

이렇게 되면 User의 행위가 사용되는 타입에 의존되게 되므로 결국 타입을 서로 치환할 수 없게 된다.

 

LSP와 아키텍처

• 자바스러운 언어 : 인터페이스 하나와 이를 구현하는 여러 개의 클래스로 구성
• 루비 : 동일한 메서드 시그니처를 공유하는 여러 개의 클래스로 구성
• 동일한 REST인터페이스에 응답하는 서비스

잘 정의된 인터페이스와 그 인터페이스 구현체끼리 상호 치환 가능성을 기대하는 사용자들이 존재.

즉 인터페이스와 구현체끼리 상호 치환을 보장하도록 구성한다

 

LSP 위배 사례

예시)

A 택시 파견 REST서비스의 URI가 존재한다.

B 택시 업체 REST 서비스 URI가 조금씩 다를 경우에

A, B 두 기업의 서비스가 합쳐질 경우... 이 예외 사항을 처리하는 로직을 추가해야만 할 것이다.

 

합병 이후 또 다른 택시업체가 인수한다면....

REST 서비스들의 인터페이스가 서로 치환 가능하지 않다는 사실을 처리하는 복잡한 메커니즘을 추가하게 될 것이다.

 

결론

LSP는 아키텍처 수준까지 확장할 수 있고, 반드시 확장해야만 한다.

치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다.