[클린아키텍처] 3부. 설계원칙 ISP

소프트웨어에서 좋은 아키텍처를 정의하는 원칙이 바로 SOLID이다.

SOLID의 원칙의 목적은 중간 수준(=모듈)의 소프트웨어 구조가 아래와 같도록 만드는 데 있다.

1. 변경에 유연하다.

2. 이해하기 쉽다.

3. 많은 소프트웨어 시스템에 사용될 수 있는 컴포넌트의 기반이 된다.

** 모듈 : 독립적인 개발 단위. 라이브러리 또는 API 인터페이스 등. 단순히 함수와 데이터구조로 구성된 집합인 클래스를 의미하기도 함.

ISP: 인터페이스 분리 원칙

---

ISP (The Interface Segregation Principle) 

클라이언트에 밀접하게 작게 쪼개진 인터페이스를 유지한다.
인터페이스의 단일 책임.
하나의 책임만을 가지는 작은 규모의 인터페이스로 분리

위의 그림에서, 다수의 사용자가 OPS 클래스의 오퍼레이션(=메서드)를 사용하고 있고,

User1은 오직 op1을 user2는 op2만을 User3는 op3만을 사용한다고 가정해보자.

OPS가 정적 타입의 언어로 작성된 코드라고 생각해보면, 이 경우 User1클래스에서는 op2와 op3를 사용하고 있지 않음에도 User1의 소스코드에서는 이 두 메서드에 의존하게 된다. (import ,use, include와 같은 타입 선언문을 통해 의존하게 된다.)

따라서 OPS 클래스에서 op2의 소스 코드가 변경되면 user1도 다시 컴파일 한 후 새로 배포해야 하는 일이 발생한다.

** 배포 이외에도, OPS 클래스에서 사용하고자 하는 메서드는 하나뿐인데, 많은 선택지가 있는것은 다른 개발자를 혼란스럽게 할 수 있다.

하지만 아래의 그림과 같이 인터페이스를 분리할 경우에는 어떻게 될까?

User 클래스들은 각각의 인터페이스에만 의존하게 되므로 OPS 클래스에서 유저가 사용하고 있는 메서드 이외의 다른 메서드를 변경하더라도 User 클래스를 재컴파일하거나 배포할 필요가 없어진다.

** 또한 User클래스들은 자신이 써야만 하는 오퍼레이션(=메서드)만 사용하도록 되어, 유지보수 및 문제 발생 시 해결이 쉬울 수 있다.

 

결론

---

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