10장 ISP: Interface Segregation Principle 인터페이스 분리 원칙

소프트웨어 설계자는 사용하지 않은 것에 의존하지 않아야 한다.

가정:

user1 은 op1 을, user2 는 op2 를, user3 는 op3 만을 사용한다

OPS 가 정적 타입 언어 클래스라면, User 는 사용하지 않는 메서드에 의존하게 된다.

이러한 의존성으로 인해 사용하지 않는 메서드가 변경되면 User 도 다시 컴파일한 후 새로 배포해야 한다.

 

위와 같이 구성하면, 자신과는 관계없는 변경이라면, 다시 컴파일하고 배포하는 상황은 생기지 않는다.

 

위의 사례는 정적 타입 언어에 해당하는 사례.

동적 타입 언어(루비, 파이썬)에서는 소스 코드에 이러한 선언문이 존재하지 않는다. 대신 런타임에 추론이 발생한다.

따라서 소스 코드 의존성이 아예 없다. 재컴파일과 재배포가 필요없다.

정적 타입 언어보다 유연하며 결합도가 낮은 시스템을 만들 수 있다.

 

그렇다면 ISP 는 아키텍처가 아닌 언어와 관련된 문제인가?

ISP와 아키텍처

ISP 를 사용하는 근본적인 동기

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

(소스코드 의존성의 경우 더욱)

불필요한 재컴파일과 재배포를 강제하기 때문이다.

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

 

<예시>

< S 시스템 구축 > → < F 프레임워크 도입 > → < D 데이터베이스 의존 >

F 에서는 불필요한 기능이 D 에 포함되어 있다면, S 와는 전혀 관계없는 기능인 것

그 기능 때문에 D 가 변경되면, F 를 재배포해야 할 수도 있고, S R까지 재배포해야 할 수도 있다.

D 내부의 기능 중 F 와 S에서 불필요한 그 기능에 문제가 발생해도 F 와 S 에 영향을 준다.

결론

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

 

사실 아직 재배포나 재컴파일이 그렇게 문제가 되는 상황을 겪어보지 않아서 이렇게 하는 방법도 있구나 싶다