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

태그

비어 있음

날짜

2024년 4월 27일

리스코프는 하위타입을 아래와 같의 정의했다.

여기에서 필요한 것은 다음과 같은 치환 원칙이다. s 타입의 객체 o1 각각에 대응하는 T 타입 객체 o2가 있고, T 타입을 이용해서 정의한 모든 프로그램 P에서 o2의 자리에 o1을 치환하더라도 P의 행위가 변하지 않는다면, S는 T의 하위 타입이다.

Personal License , Business License 두 가지 하위 타입은 라이선스 비용을 계산한다.

이 설계는 LSP를 준수한다. 

 Billing 애플리케이션의 행위가 하위타입 중 무엇을 사용하느지에 의존하지 않기 때문에,

 하위타입들을 모두 License 타입을 치환할 수 있다.

LSP를 위반하는 전형적인 문제

Rectangle : 높이와 너비 독립적 ↔ Square : 높이와 너비 독립적 x

→ 적절한 하위타입이 아님

Java

복사

Rectangle r = ...
r.setW(5)
r.setH(2)
assert(r.area() == 10);

만약 이 코드에서 Square를 생성한다면 assert문을 실패한다.

User에 이 둘을 구분하는 로직을 추가하면 User의 행위가 사용하는 타입에 의존하게 되므로, 
결국 타입을 서로 치환할 수 없게 된다.

LSP는 상속을 사용하도록 가이드하는 방법 정도로 간주되었지만,

인터페이스와 구현체에도 적용되는 더 광범위한 소프트웨어 설계 원칙으로 변모 

아키텍처 관점에서 LSP를 이해하는 최선의 방법은 이 원칙을 어겼을 때 시스템 아키텍처에서 무슨 일이 일어나는지 관찰하는 것이다.

시스템에 정보를 요구하는 REST 인터페이스

Java

복사

purplecab.com/driver/Bob
	/pickupAddress/24 Maple St.
    /pickupTime/153
    /destination/ORD

만약 destination 필드 대신 dest를 사용하는 업체가 있다면?

만약  다른 업체를 인수한다면?

⇒ if를 사용해 구분, 복잡한 매커니즘 추가 , 온갖 종류의 에러 , 보안 침해 

아키텍트는 이 같은 버그로부터 시스템을 격리해야 한다. 

LSP는 아키텍트 수준까지 확장할 수 있고, 반드시 확장해야만 한다. 치환 가능성을 조금이라도 위배하면 시스템 아키텍처가 오염되어 상당량의 별도 메커니즘을 추가해야 할 수 있기 때문이다.

programming::鈍筆勝聰