설계원칙 - SOLID(ISP)

- 이 글은 로버트 C.마틴의 Clean Architecture를 기반으로 작성되었습니다. (가능하면 책을 읽어보는것을 추천한다.)

- 로버튼 C.마틴, ISP vs SRP: https://twitter.com/unclebobmartin/status/996739060348653568

- 개요

위와 같은 다이어그램에서 Employee는 searchByEmployee()를 통해서 제품검색을 하며, Customer는 searchByCustomer()를 그리고 CEO는 report를 보기 위해 generateReport() 함수를 사용한다.

 

Employee, Customer, CEO는 1개의 메소드씩만 사용하지만 ProductService에 함수를 다 정의해놓고 의존하다보니 자신이 사용하지 않는 다른 두 메소드에도 의존하게 된다. 

 

이런 문제는 오퍼레이션을 Interface를 사용하여 분리하면 아래 다이어그램과 같은 의존관계로 해결할 수 있다.

Employee는 EmployeeProductService 에는 의존하지만 ProductService에는 의존하지 않게 된다. ProductService의 변경이 Employee와 관계가 없다면 Employee를 다시 배포(다이어 그램에서는 Actor로 표현하였지만 소스코드 관점에서) 하지 않아도 된다. 

---

- ISP와 언어

정적 타입의 언어에서는 import(Java의 경우)와 같이 타입 선언문 사용을 강제한다. 하지만 파이썬 같은 동적 타입의 언어에서는 선언문이 존재하지 않는다. 따라서 이런 의존성이 생기지 않아 재배포 및 재컴파일을 하지 않아도 되어 결합도가 낮은 시스템이 된다.

---

- ISP vs SRP

위 다이어그램을 보고 한 가지 의문점이 있을 수 있다. 나도 블로그를 쓰기 위해 위 다이어그램을 그렸지만 인터페이스에 대해서 ISP와 SRP가 매우 비슷하여 본질적으로 무엇이 다른지 헷갈렸다는 점이다. 두 차이점에 대해서 검색을 해보니 나와 비슷한 의문이 가진 사람이 있었고, 마틴은 친절하게도 트윗을 달아주었다.

 

ISP는 Client가 필요한것 이상에 의존하지 않는것이고, SRP는 같은 이유와 타이밍에 변경되는 것들을 함께 모으라는 의미인것이다.

---

- 결론

ISP(인터페이스 분리 원칙)은 자신이 필요한 행위를 넘어 불필요한것에 의존하면 문제가 생길 수 있다는 교훈을 준다. 이는 컴포넌트 응집도와 관련되어 공통 재사용원칙과도 연관이 있다.