출처
클린 아키텍처를 읽으며 정리한 내용입니다.
10. ISP: 인터페이스 분리 원칙
여러 사용자(User1, User2, User3)가 OPS라는 하나의 클래스를 같이 사용하는 경우를 가정해보자. 이 사용자들이 OPS 클래스의 오퍼레이션을 사용하지만, 각각 서로 다른 오퍼레이션(각각 op1, op2, op3)만을 사용한다면 어떨까?
정적 타입 언어로 작성된 경우, 그럴 필요가 없는데도 User1의 소스 코드는 op2와 op3에 의존하게 된다. 따라서 op2가 변경되면 User1도 다시 컴파일한 후 새로 배포해야 한다.
이러한 문제는 오퍼레이션을 각 유저가 사용하는 기능 별 인터페이스로 분리하고, 세 가지 인터페이스를 구현하는 구체 클래스 하나를 만들어 개발 독립성과 배포 독립성을 가져갈 수 있다.
ISP와 언어
앞의 예제에서 본 사례는 언어 타입에 의존한다.
정적 타입 언어의 경우 import, include같은 타입 선언문을 사용해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일/재배포가 강제되는 상황이 초래된다.
하지만 루비나 파이썬 등 동적 타입 언어에서는 소스 코드에 선언문이 존재하지 않고, 런타임에 추론이 발생한다. 따라서 소스 코드 의존성이 아예 없으며 재컴파일과 재배포도 필요 없다.
이런 특성때문에 동적 타입 언어를 사용하면 더 유연하며 결합도가 낮은 시스템을 만들 수 있다! 하지만 그렇다고 해서 ISP가 언어와 관련된 문제일까?
ISP와 아키텍처
아키텍처에서도 필요 이상으로 많은 것을 포함하는 모듈에 의존하는 위와 같은 상황이 발생할 수 있다..
S 시스템 구축에 참여하고 있는 아키텍트는 F라는 프레임워크를 시스템에 도입했고, F 프레임워크 개발자는 특정한 D 데이터베이스를 반드시 사용하도록 만들었다고 가정해보자. S는 F에 의존하고, F는 D에 의존하게 된다.
D 내부에서 F가 사용하지 않는 기능에 대해 변경이 발생하면 F를 재배포해야 할 수 있고, 경우에 따라서 S까지 재배포해야 할 수 있다. 심지어 이 기능에 문제가 발생하면 F와 S까지 영향을 받는다.
결론
불필요한 짐을 실은 무언가에 의존하면 예상치 못한 문제에 빠질 수 있다.
