[Clean Architecture] 10. ISP: 인터페이스 분리 원칙.

Key Points

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

ISP: 인터페이스 분리 원칙

인터페이스 분리 원칙은 아래 다이어그램에서 이름이 유래됨

다수의 사용자가 OPS 클래스의 오퍼레이션을 사용하고 각 유저들은 각자 다른 하나의 오퍼레이션만 사용한다.

• User1 -> op1
• User2 -> op2
• User3 -> op3

정적 타입 언어인 경우 User1이 op2,op3를 전혀 사용하지 않음에도 User1의 소스 코드는 이 두 메서드에 의존하게 됨
이러한 의존성으로 인해 OPS 클래스에서 op2 코드가 변경되면 User1도 다시 컴파일 해야함

따라서 아래처럼 변경

오퍼레이션 분리

• 인터페이스를 두고 오퍼레이션을 분리
• User1 -> U10ps(op1) 에는 의존하지만 OPS 클래스에는 의존하지 않게 됨.
• 따라서 OPS의 op2의 변경은 User1과는 전혀 관계없으므로 재컴파일 필요 X

ISP와 언어

정적 타입 언어는 사용자가 import, use, include와 같은 타입 선언문을 사용하도록 강제함. 이러한 선언문으로 인해 소스 코드 의존성이 발새아고 이로 인해 재컴파일, 재배포가 강제되는 상황이 무조건 초래한다.

이러한 사실로 인해 ISP를 아키텍처가 아니라, 언어와 관련된 문제라고 결론내릴 여지가 있다.

참고

• 자바는 late binding을 수행
• 비 final, 비 private 인스턴스 변수에 대해 호출할 정확한 메서드를 런타임에 늦게 결정
• 따라서 10.1에서 op2의 메서드 변경시 User2만 재컴파일하면 됨

ISP와 아키텍처

일반적으로 필요 이상으로 많은걸 포함하는 모듈에 의존하는것은 해로운 일

소스 코드 의존성의 경우 이는 분명한 사실인데, 불필요한 재컴파일과 재배포를 강제하기 때문.

하지만 더 고수준인 아키텍처 수준에서도 마찬가지 상황이 발생함.

F에서는 불필요한 기능, 따라서 S에서 불필요한 기능이 D에 포함되었다고 가정하자.

• 그 기능때문에 D가 변경되면 F를 재배포
• S까지 재배포해야 할지 모른다.