• 인터페이스 분리 원칙(ISP)은 아래의 다이어그램에서 그 이름이 유래
• OPS가 정적 타입 언어로 작성된 클래스라고 해보자
• User1에서는 op2, op3를 전혀 사용하지 않음에도 이 두 메서드에 의존하게 된다
• OPS 클래스에서는 op2의 소스 코드가 변경되면 User1도 다시 컴파일한 후 새로 배포
• 그림 10.2 분리된 오퍼레이션
• 그림 10.2처럼 오퍼레이션을 인터페이스 단위로 분리하면 해결 가능
• 정적 타입 언어로 이 다이어그램을 구현했다고 가정하면, User1의 소스 코드는 U10ps와 op1에는 의존하지만 OPS에는 의존 X
• OPS에서 발생한 변경이 User1과는 전혀 관계없는 변경이라면, User1을 다시 컴파일하고 새로 배포하는 상황은 초래 X

ISP와 언어

• 정적 타입 언어는 사용자가 import, use 또는 include와 같은 타입 선언문을 사용하도록 강제
• 소스 코드에 '포함된(included)' 선언문으로 인해 소스 코드 의존성이 발생하여, 재컴파일 또는 재배포 초래
• 루비나 파이썬과 같은 동적 타입 언어에서는 소스 코드에 이러한 선언문이 존재하지 않지만, 런타임에 추론 발생
• 소스 코드 의존성이 아예 없으며, 결국 재컴파일과 재배포가 필요없다.
• 동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유는 바로 이 때문

ISP와 아키텍처

• ISP를 사용하는 근본적인 동기를 살펴보면, 잠재되어 있는 더 깊은 우려사항 확인 가능
• 필요 이상으로 많은걸 포함하는 모듈에 의존하는 것은 해로운 일이다
• 소스 코드 의존성의 경우 이는 분명한 사실인데, 불필요한 재컴파일과 재배포를 강제하기 때문
• 하지만 더 고수준 아키텍처 수준에서도 마찬가지 상황이 발생
• 그림 10.3 문제가 있는 아키텍처