clean-architecture

10장. ISP: 인터페이스 분리 원칙

Introduction

• 그리고 OPS 가 정적 타입 언어로 작성된 클래스라고 해보자
• 이 경우 User1 에서는 op2, op3 를 전혀 사용하지 않음에도 User1 의 소스코드는 이 두 메서드에 의존하게 됨
• 이러한 의존성으로 인해 OPS 클래스에서 op2 의 소스코드가 변경되면 User1 도 다시 컴파일 후 새로 배포해야 함
  • 사실 User1 과 관련된 코드는 전혀 변경되지 않았지만!
• 이런 문제는 아래처럼 인터페이스 단위로 오퍼레이션을 분리하여 해결할 수 있음

ISP와 언어

• 앞의 예제는 언어 타입에 의존함
• 정적 타입 언어는 사용자가 import, user 또는 include 같은 타입 선언문을 사용하도록 강제함
• 이처럼 소스코드에 ‘포함된 included’ 선언문으로 인해 소스 코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제되는 상황이 무조건 초래됨
• 동적 타입 언어에서는 소스코드에 이러한 선언문이 존재하지 않는다.
  • 대신 런타임에 추론이 발생한다.
  • 따라서 소스 코드 의존성이 아예 없으며, 결국 재컴파일과 재배포가 필요없다.
• 동적 타입 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들 수 있는 이유는 바로 이 때문
• 이러한 사실로 인해 ISP 를 아키텍처가 아니라, 언어와 관련된 문제라고 결론내릴 여지가 있다.
  • ISP 는 언어 종류에 따라 영향받는 정도가 다르다.

ISP와 아키텍처

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

• S 시스템에서 F 프레임워크를 시스템에 도입하고자 하고, F 프레임워크 개발자는 D 데이터베이스를 반드시 사용하도록 만들었다고 가정
• S 는 F 에 의존하고, F 는 다시 D 에 의존하게 됨
• F 에서는 불필요한 기능, 따라서 S 와는 전혀 관계없는 기능이 D 에 포함된다고 가정
• 그 기능 때문에 D 내부가 변경되면, F 를 재배포해야 할 수도 있고, 따라서 S 까지 재배포해야 할지 모름
• 더 심각한 문제는 D 내부의 기능 중 F 와 S 에서 불필요한 그 기능에 문제가 발생해도 F 와 S 에 영향을 준다는 사실

결론

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