SOLID (5) - 인터페이스 분리 원칙, ISP

인터페이스 분리 원칙 (ISP, Interface Segregation Principle)

프로그래밍 능력에 변화가 생기더라도 외국어 능력이나 발표 능력을 사용하는 영업 업무에는 영향을 미치지 않을 확률이 높지만 개발 업무 부서에는 영향을 미칠 수 있다.

ISP는 위의 관점(클라이언트의 관점에서 바라는)에서 생긴 객체지향 설계 원칙에는 클라이언트 자신이 이용하지 않는 기능에는 영향을 받지 않아야 한다는 내용이 담겨있다.

복합기 기능을 제공하는 클래스는 매우 비대해질 가능성이 크다. 하지만 이 비대한 클래스의 모든 기능을 클라이언트가 동시에 사용하는 경우는 거의 없다. 클라이언트의 필요에 따라 프린터, 팩스, 복사기 중 하나의 기능만 이용할 수 있다.

따라서 프린터 기능만 이용하는 클라이언트가 팩스 기능의 변경으로 인해 발생하는 문제의 영향을 받지 않도록 해야 한다.

클라이언트와 무관하게 발생한 변화로 클라이언트 자신이 영향을 받지 않으려면 범용의 인터페이스보다는 클라이언트에 특화된 인터페이스를 사용해야 한다. 즉, ISP를 다르게 설명하면 말 그대로 인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙이라고도 할 수 있다.

복합기 클래스에 ISP 원칙을 적용한 결과는 다음과 같다.

복합기 클래스에 ISP를 적용한 예

복합기를 사용하는 객체들마다 자신이 관심을 갖는 메서드들만 있는 인터페이스를 제공받고록 설계.

이렇게 설계하면 인터페이스가 일종의 방화벽 역할을 수행해 클라이언트는 자신이 사용하지 않는 메서드에 생긴 변화로 인한 영향을 받지 않게 된다.

SRP와 ISP 사이의 관계를 생각해보자. 어떤 클래스가 단일 책임을 수행하지 않고 여러 책임을 수행하게 되면 방대한 메서드를 가진 비대한 클래스가 될 가능성이 커지며, 당연히 비대한 인터페이스가 제공될 것이다.

이렇게 비대한 클래스를 SRP에 따라 단일 책임을 갖는 여러 클래스들로 분할하고 각자의 인터페이스를 제공한다면 ISP도 만족할 수 있다.

그렇다고해서 "ISP는 SRP를 만족하면 성립되는 것인가?"라는 질문에 대해서는 반드시 그렇다고 할수는 없다.

가령 게시판의 여러 기능을 구현한 메서드를 제공하는 클래스가 있다고 하고, 이 클래스에는 글쓰기, 읽기, 수정, 삭제를 위한 메서드가 제공된다. 그러나 클라이언트에 따라서는 게시판의 이러한 기능 중 일부분만을 사용할 수도 있다.

예를 들어 일반 사용자는 게시판 삭제 기능이 없지만 관리자는 삭제가 가능하다.

이런 경우 게시판 클래스는 게시판에 관련된 책임을 구행하므로 SRP를 만족한다.

그러나 이 클래스의 모든 메서드가 들어 있는 인터페이스가 클라이언트에 상관없이 사용된다면 ISP에 위배된다.