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

하위 타입에 관한 원칙
상호 대체 가능한 구성요소를 이용해 소프트웨어 시스템을 만들 수 있으려면, 이들 구성 요소는 반드시 서로 치환 가능해야 한다.

S 타입 객체 o1 각각에 대응하는 T 타입 객체 o2 가 있고, o2 자리에 o1 을 치환하더라도 프로그램의 행위가 변하지 않는다면

S 는 T 의 하위 타입이다.

예제

Billing 애플리케이션에서 License의 calcFee() 호출

LSP 준수 설계 → Billing 애플리케이션의 행위가 License 의 하위 타입 중 뭘 사용하는지에 대해 의존하지 않음

 

정사각형/직사각형 문제 → LSP 위반

• Rectangle 의 높이와 너비는 서로 독립적으로 변경될 수 있는 반면, Square의 높이와 너비는 반드시 함께 변경됨

LSP 위반을 막기 위해 실제 타입이 Square 인지를 검사

🚨 User 의 행위가 사용하는 타입에 의존하게 됨 → 타입 치환 불가

 

LSP와 아키텍처

아키텍처 관점에서 LSP를 이해하는 최선의 방법

이 원칙을 어겼을 때, 시스템 아키텍처에서 무슨 일이 일어나는지 관찰하는 것이다.

LSP 위배 사례

택시 파견 서비스 통합 애플리케이션

고객이 이용할 택시를 결정하면 시스템은 REST 서비스를 통해 선택된 택시를 고객 위치로 파견

bob: /driver/bob
other-driver: /driver/%s

파견에 필요한 정보를 덧붙인 URI 인터페이스를 정의

→ 이 인터페이스를 준수하지 않는 업체로 인해 규칙이 추가되는 경우

코드에 if 문을 넣어 추가하는게 아니라, 파견 URI 를 key 로 사용하는 설정용 데이터베이스를 이용하는 파견 명령 생성 모듈을 만들어야 할 수도 있다.

또한 아키텍트는 REST 서비스들의 인터페이스가 서로 치환 가능하지 않다는 사실을 처리하는 중요하고 복잡한 매커니즘을 추가해야 한다.

치환 불가
*: domain/call-driver/bob/destination...

acme: domain/call-driver/bob/dest...

결론

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

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