ISP:인터페이스 분리 원칙

이미지 출처 : https://wedonttalknemore.tistory.com/17?category=967824

• 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용하고, 각 User별 매칭되는 오퍼레이션은 아래와 같다.
  • User1 - op1만 사용 / User2 - op2만 사용 / User3 - op3만 사용
  • 문제점
    • User1에서는 op2와 op3를 전혀 사용하지 않지만 User1의 소스 코드는 이 두 메서드에 의존하게 된다.
    • 따라서 OPS 클래스에서 op2의 소스 코드가 변경되면 User1도 다시 컴파일한 후 새로 배포해야 한다. (User1과 관련된 코드는 전혀 변경되지 않았다.)
  • 해결책

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

      

    • User1의 소스 코드는 U1Ops와 op1에는 의존하지만 OPS에는 의존하지 않게 된다.

      → OPS에서 발생한 변경이 User1과는 전혀 관계없는 변경이라면, User1을 다시 컴파일하고 새로 배포하는 상황은 초래되지 않는다.
      

ISP와 언어

• 정적 언어 타입(컴파일 언어, C, Java..)

  • 사용자가 import, use, 또는 include와 같은 타입 선언문을 사용하도록 강제한다.
  • 소스 코드에 포함된(included) 선언문으로 인해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제되는 상황이 무조건 초래된다.

• 동적 언어 타입(인터프리터 언어, 루비, 파이썬)

  • 소스 코드에 이러한 선언문이 존재하지 않는다.
  • 대신 런타임에 추론이 발생한다.
  • 따라서 소스 코드 의존성이 아예 없으며, 결국 재컴파일과 재배포가 필요 없다.
  • 동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들어 수 있는 이유는 바로 이 때문이다.

• 위와 같은 사실로 ISP를 아키텍처가 아니라, 언어와 관련된 문제라고 결론내릴 여지가 있다.

ISP와 아키텍처

• 일반적으로 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 소스코드와 아키텍처 두 수준 모두에게 큰 비용을 치루게 한다.
  • 불필요한 재컴파일과 재배포를 강제하기 때문이다.