10. ISP - 인터페이스 분리 원칙
이번엔 SOLID의 I에 해당하는 인터페이스 분리 원칙(Interface segregation principle) 이다.
인터페이스 분리 원칙은 아래 다이어그램에서 유래된 원칙이다.
위의 그림은 다수의 사용자가 OPS 클래스의 오퍼레이션을 사용한다.
User1은 오직 op1()을, User2는 오직 op2()를, User3는 오직 op3()만을 사용한다고 가정한다.
여기서 OPS가 정적 타입 언어로 작성된 클래스라고 해보자.
이 경우 User1에서는 op2()와 op3()를 전혀 사용하지 않음에도 불구하고, User1의 소스 코드는 이 두 메서드에 의존성을 가지게 된다.
이러한 의존성으로 인해 OPS 클래스에서 op2() 메서드가 변경되면 전혀 상관없는 User1도 다시 컴파일 후 배포되어야 한다.
이러한 문제는 아래 그림처럼 오퍼레이션을 인터페이스 단위로 분리하여 해결할 수 있다.
위와 같이 작성하면 User1의 소스 코드는 U1Ops와 op1()에는 의존하지만 OPS에는 의존하지 않게 된다.
10.1. 인터페이스 분리 원칙과 언어
위의 사례는 언어 타입에 의존한다.
정적 타입 언어는 사용자가 import, include, use 등과 같은 타입 선언문을 사용하도록 강제한다.
이처럼 소스 코드에 포함된 선언문으로 인해 소스 코드 의존성이 발생하게 되고, 이로인한 컴파일과 배포가 강제되는 상황이 수반된다.
반면 동적 타입 언어에서는 런타임에 타입을 추론하므로 별도의 소스 코드 의존성이 존재하지않고 컴파일과 배포도 수반되지 않는다.
이것이 동적 타입언어가 정적 타입 언어보다 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유이기도 하다.
이러한 사실로 인터페이스 분리 원칙은 아키텍처가 아니라 언어와 관련된 문제라고 결론내릴 여지도 존재한다.
10.2. 인터페이스 분리 원칙과 아키텍처
인터페이스 분리 원칙를 사용하는 근본적인 동기를 살펴보면, 잠재되어 있는 우려사항을 확인할 수 있다.
일반적으로 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다.
소스 코드 의존성의 경우 이는 분명한 사실인데, 불필요한 재컴파일과 재배포를 강제하기 때문이다.
하지만 더 고수준인 아키텍처 수준에서도 동일한 상황이 발생한다.
선형적인 의존성을 가진 경우 불필요한 기능과 변경이 최종 시스템에 영향을 주는 상황이 초래될 수 있기 때문이다.
