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

SOLID는 객체 지향 설계 원칙으로 프로그램을 읽기 쉽고 확장이 용이하며 리팩토링시 간편하게 수정을 할 수 있도록 하는 설계 원칙입니다.

 

SOLID는

SRP - 단일 책임 원칙

OCP - 개방 폐쇄 원칙

LSP - 리스코프 치환 원칙

ISP - 인터페이스 분리 원칙

DIP - 의존 역전 원칙

으로 구성됩니다.

 

여기서 ISP. 즉, 인터페이스 분리 원칙에 대해서 알아보겠습니다.

 

ISP

ISP는 인터페이스를 클라이언트가 필요로 하는 기능에 따라 분리해야 한다는 원칙으로,

의존성을 분리해 모듈 간의 결합도를 낮추고 유연성을 높이는 것이 목적인 설계 원칙입니다.

인터페이스가 작고 응집도가 높아질수록 클래스 간의 관계가 단순해지고 변경 사항에 대한 유지보수성도 향상됩니다.

 

다시 말해 ISP란, 범용적인 인터페이스보다는 사용자가 실제로 사용하는 Interface를 만들어야 한다는 의미로 인터페이스를 사용에 맞게 끔 각각 분리해야 한다는 설계 원칙입니다.

 

인터페이스의 추상 메서드들을 범용적으로 여러 개 구현한다면 그 인터페이스를 상속 받는 클래스는 필요하지도 않은 인터페이스마저 구현해야 될 수 있습니다. 따라서 ISP는 인터페이스를 잘게 분리함으로써 클라이언트의 목적과 용도에 적합한 인터페이스만 제공하게 해줍니다.

 

 

위와 같이 Pet인터페이스를 좀 더 작게 나눔으로써 각 애완동물 클래스의 역할과 맞게 상속시켜줌으로서, 클래스의 기능을 쉽게 파악할 수 있다는 이점을 얻을 수 있으며 유연하게 객체의 기능을 확장하거나 수정할 수 있게 됩니다.

 

 

인터페이스 분리 원칙은 SRP와 비슷하게 볼 수 있는데,

SRP는 클래스의 단일 책임을 강조한다면, ISP는 인터페이스의 단일 책임을 강조하는 것입니다.

다만, 인터페이스는 클래스와 다르게 추상화이기 때문에 여러 개의 역할을 가지는데 제약이 없어 인터페이스가 자칫 몸집이 커질 수 있습니다. 따라서 관련있는 기능끼리 하나의 인터페이스에 모으되 지나치게 커지지 않도록 크기를 제한해야 합니다.

 

※ ISP 원칙 적용의 주의점

인터페이스 분리는 한 번만 할 것입니다.

ISP 원칙의 주의점은 한 번 인터페이스를 분리해 구성해놓고 나중에 수정사항이 생겨 또 인터페이스를 분리하는 행위를 하지 말라는 점입니다.

 

이미 구현되어 있는 프로젝트에 또 인터페이스들을 분리한다면, 해당 인터페이스를 구현하고 있는 온갖 클래스들과 이를 사용하고 있는 클라이언트에서 문제가 발생할 수 있기 때문입니다. -> 본래 인터페이스라는 것은 한 번 구성했으면 수정이 불가피하지 않는 이상 변하면 안되는 정책같은 개념입니다.

 

 

SRP가 클래스의 단일 책임 원칙이라면, ISP는 인터페이스의 단일 책임 원칙?

즉, 인터페이스 안에 기능에 대한 책임에 맞게 추상 메소드를 구성하면 된다는 의미입니다.

하지만, 책임을 준수하더라도 ISP가 만족되지 않을 수 있는 케이스가 존재합니다.

위와 같이 게시판 인터페이스에 글쓰기, 읽기, 삭제 추상 메서드가 정의되어 있는데, 모두 게시판에 필요한 기능들이며 게시판만을 이용하는 단일 책임에 위배되지 않습니다.

 

하지만, 이를 구현하는 일반 사용자 입장에서 게시글 강제 삭제 기능은 사용할 수 없기 때문에 결국 ISP 위반으로 이어지게 됩니다.

 

따라서 책임을 잘 구성해 놓은 것 같지만 실제 적용되는 객체에겐 부합되지 않을 수 있기 때문에 책임을 더 분리해야 합니다.

 

결국 ISP는 SRP를 만족하면 성립되는가라는 질문에 단호하게 그렇다고 말 할 수는 없을 것 같습니다.

 

---

출처: https://inpa.tistory.com/entry/OOP-%F0%9F%92%A0-%EC%95%84%EC%A3%BC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EB%8A%94-ISP-%EC%9D%B8%ED%84%B0%ED%8E%98%EC%9D%B4%EC%8A%A4-%EB%B6%84%EB%A6%AC-%EC%9B%90%EC%B9%99?category=967430