SOLID - 인터페이스 분리 원칙(Interface Segregation Principle)

 

본 글은 자바 객체지향과 디자인패턴를 읽고 개인적으로 학습한 내용을 복습하기 위해 작성된 글로 내용상 오류가 있을 수 있습니다. 오류가 있다면 지적 부탁드리겠습니다.

1. 인터페이스 분리 원칙이란?

예를 들어 설명해보자면 아래의 그림과 같이 프린터, 팩스, 복사기 기능이 모두 포함된 복합기가 있다고 가정해보자.

복합기의 클래스 다이어그램

위의 그림처럼 복합기 기능을 제공하는 클래스는 매우 비대해질 가능성이 크다. 이 비대한 클래스의 모든 기능을 클라이언트가 동시에 사용하는 경우는 거의 없다. 클라이언트의 필요에 따라 프린터 기능만을 또는 팩스 기능만 그리고 복사기 기능만 사용할 수도 있다. 따라서 프린터 기능만을 사용하는 클라이언트에서는 팩스 기능의 변경으로 인해 발생하는 문제에 영향을 받지 않아야한다. 클라이언트와 무관하게 발생한 변화로 클라이언트 자신이 영향을 받지 않으려면 범용의 인터페이스보다는 클라이언트에 특화된 인터페이스만을 사용해야만한다. 즉, ISP는 인터페이스를 클라이언트에 특화되도록 분리시키라는 설계 원칙이다.

그렇다면 ISP원칙에 위배되지 않게 복합기를 설계하면 다음 그림과 같은 모습이 된다.

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

복합기를 사용하는 객체들마다 자신이 관심을 갖는 메서드만있는 인터페이스를 제공받도록 설계했다. 이렇게 설계하면 인터페이스가 일종의 방화벽 역할을 수행하여 클라이언트는 자신이 사용하지 않는 메서드에 변화로 인한 영향을 받지 않게 된다.

SRP와 ISP 사이의 관계를 생각해보자. 어떤 클래스가 단일 책임을 수행하지 않고, 여러 책임을 수행하게 되면 당연히 방대한 메서드를 가진 비대한 클래스가 될 가능성이 높아지고, 비대한 인터페이스가 제공될 것이다. 이렇게 비대한 클래스를 SRP에 따라 단일 책임을 갖는 여러 클래스로 분할하고, 각자의 인터페이스를 제공한다면 ISP도 만족할 수 있다.

그렇다면 ISP는 SRP를 만족하면 성립할까? 아니다 반드시 그렇다고는 볼 수 없다.

만약 게시판의 여러기능을 구현한 메서드를 제공하는 클래스가 있다면 이 클래스는 글쓰기, 읽기, 수정, 삭제를 위한 메서드가 제공될 것이다. 그러나 클라이언트에 따라서는 게시판의 이러한 기능 중 일부분만을 사용할 수도 있다. 예를 들어 일반 사용자는 게시판 삭제기능이 없지만 관리자는 삭제를 할 수 있다. 이런 경우 게시판 클래스는 게시판에 관련된 책임을 수행하므로 SRP를 만족한다. 그러나 이 클래스의 모든 메서드가 들어있는 인터페이스가 클라이언트에 상관없이 사용된다면 ISP에 위배되기 때문이다.