10장. ISP: 인터페이스 분리 원칙(interface Segregation Principle)

10장. ISP: 인터페이스 분리 원칙(interface Segregation Principle)

소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다.

 

위 그림의 상황에서 User1은 op1만을, User2는 op2만을, User3은 op3만을 사용한다고 가정해보자.

또, OPS가 정적타입언어로 작성된 클래스라고 가정해보자.

이 경우 User1은 op2, op3을 사용하지 않음에도 소스코드는 의존하게된다.

 

(만약, op2코드가 변경되면 User1과 관련된 코드는 전혀 변경되지 않았더라도 재컴파일후 배포해야한다.)

 

아래처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다.

 

ISP와 언어

• 정적 타입언어 (java) : 사용자가 import, use, include 같은 타임 선언문을 반드시 사용해야한다. 즉 include 선언으로 인한 소스코드 의존성이 발생하고, 이로 인해 재컴파일 및 재배포가 강제되는 상황이 무조건 초래된다.
• 동적 타입 언어(루비, 파이썬): 소스코드에 선언문이 존재하지 않고 런타임에서 추론이 발생한다. 따라서 소스코드의 의존성이 아예 없으며 재컴파일과 재배포가 필요없다.

즉, 동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들 수 있다.

따라서, ISP를 아키텍처가 아니라 언어와 관련된 문제라고 결론내릴 여지가 있다.

 

ISP와 아키텍처

일반적으로, 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다. (불필요한 컴파일과 재배포를 유발)

고수준인 아키텍처 수준에서도 마찬가지다.

 

<고수준 아키텍처 수준 예시>

S 시스템에 F 프레임워크를 도입하고 싶다.

F 프레임워크는 D 데이터베이스를 반드시 사용하도록 설계되어있다.

S→ F→D

S는 F에 의존하며, F는 D에 의존

- 가지는 문제1 : S와 관련 없는 기능이 D에 추가될 경우, D의 변경으로 인해 F를 재배포 할 수 있으며, S까지 재배포해야할지도 모른다.

- 가지는 문제2 : D의 내부의 기능중 F와 S에서 불필요한 기능에 문제가 발생해도 F와 S에 영향을 준다.

 

결론

불필요한 짐을 실은 무언가에 의존하면 예상치도 못한 문제에 빠진다.