소개

클린아키텍처: 소프트웨어 구조와 설계의 원칙 책을 읽고 정리하며 소감을 적는 포스트입니다.

ISP: 인터페이스 분리 원칙

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

인터페이스 분리 원칙

User1은 오직 op1을 User2는 op2만을, User3는 op3만을 사용한다고 가정한다.

이 경우 User1은 op2와 op3를 전혀 사용하지 않음에도 User1의 소스코드는 이 두 메서드에 의존하게 된다.

이러한 의존성으로 인해 op2가 수정되면 User1도 다시 컴파일 후 새로 배포해야 한다.

그래서 아래와 같인 인터페이스를 분리해여 관리 하여야 한다.

분리된 오퍼레이션

앞에서 본 사례는 언터 타입에 의존한다. 정적 타입 언어는 사용자가 import, use 또는 include와 같은 타입 선언문을 사용하도록 강제 한다.

이처럼 소스 코드에 포함된included 선언문으로 인해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제되는 상황이 무조건 초래한다.

루비나 파이썬 같은 동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들 수 있다.

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

일반적으로 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운 일이다. 소스코드 의존성의 경우 이는 분명한 사실인데, 불필요한 재컴파일과 재배포를 강제하기 때문이다. 하지만 더 고수준인 아키텍처 수준에서도 마찬가지 상황이 발생한다.

문제가 있는 아키텍처

위 그림은 S 시스템 구축에 참여하는 아키텍트가 F라는 프레임워크를 시스템에 도입하기를 원한다. 그리고 F 프레임워크 개발자는 특정한 D 데이터베이스를 반드시 사용하도록 만들었다고 가정한다.

따라서 S는 F에 의존하며, F는 다시 D에 의존하게 된다.

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