- Interface Separation Principle
OPS라는 클래스는 op1, op2, op3라는 메서드를 가지고 있음User1 클래스는 op1, User2 클래스는 op2, User3 클래스는 op3을 사용User1은 op2를 사용하고 있지 않지만 op2가 변경이 되면 User1도 다시 컴파일, 배포가 필요 User1과 관련된 코드는 변경이 없었음에도!
- 오퍼레이션을 인터페이스 단위로 분리해서 해결가능
User1은 U1Ops를 사용OPS는 U1Ops를 구현op2가 변경해도 User1을 다시 컴파일할 필요가 없어짐
ISP와 언어
- 위 예시는 언어 타입에 의존
- 정적 타입 언어는
import, use 또는 include와 같은 타입 선언문 사용을 강제함 - 소스 코드의 포함된 선언문으로 인해 소스 코드 의존성이 발생
- 의존성이 존재하는 코드를 수정하면 재컴파일 또는 재배포가 강제되는 상황이 발생
- 루비나 파이썬 같은 동적 타입 언어는 런타임에 추론이 발생
- 소스 코드의 의존성이 없음
- 동적 타입을 언어를 사용하면 정적 타입 언어를 사용할 때보다 유연하며 결합도가 낮은 시스템을 만들수 있는 이유가 이때문
- 위와 같은 사실로 ISP는 아키텍처가 아니라 언어와 관련된 문제라고 결론내릴 여지가 있음
ISP와 아키텍처
- IPS를 사용하는 근복적인 동기를 살펴보면, 잠재되어 있는 더 깊은 우려사항을 볼 수 있음
- 필요 이상으로 많은 걸 포함하는 모듈에 의존하는 것은 해로운일
- 다음과 같은 의존성 관계가 존재
System S -> Framework F -> Database D- F에서 불필요한 기능이 D에 존재, 즉 S와 전혀 관계없는 기능이 D에 존재
- 그 기능때문에 D 내부가 변경되면 S까지 영향이 발생
결론
- 불필요한 무언가를 의존하면 예상하지 못한 문제가 발생할 수 있음
- 13장 “컴포넌트 응집도”에서 공통 재사용 원칙을 논할때 자세히 다룸