ISP 인터페이스 분리의 원칙

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

 

Note

  인터페이스 분리의 원칙은 기능의 분리로 볼 수 있다. I/O의 기본을 입력과 출력으로 나눈다면 입력이라는 기능과 출력이라는 기능으로 나눌 수 있음을 직관적으로 느낄 수 있다. 이러한 기준은 인터페이스 분리의 원칙에 그대로 적용할 수 있다. 파일의 입력은 Input이라는 인터페이스로 출력은 output이라는 인터페이스로 분리가 가능하다는 뜻이다. 아마도 이렇게 분리된 휼륭한 코드를 본 바 있으리라 생각된다. 자바의 Input, Output API 시리즈가 가장 대표적인 ISP의 표본이지 않을까. 클라이언트가 파일에 Access 하고자 할 때는 입력과 출력을 염두에 둘 것이다. 하지만 대부분의 경우 입력 설계와 출력 설계가 항상 함께이지는 않을 것이고, 사용하지도 않는 부분에 대해 의존적인 코드가 생산될 가능성이 항상 존재 한다.

 

  기능을 분리하는 형태 때문에 SRP(단일책임의 원칙) 와 혼동하는 경우는 없기 바란다. "책임"과 "인터페이스"는 명백한 차이를 가진다. 차이의 설명을 위해 억지로 섞어서 생각한다면 그림 1-1은 파일에 관한 책임 만을 가지므로 SRP를 위배하지 않았지만 분리가능한 인터페이스를 함께 가지고 있으므로 ISP는 위배하고 있다. 인터페이스 분리의 원칙을 지키기 위해서는 지나친 일반화를 경계해야 한다. 그림 1-1의 경우는 파일에 대한 일반화 과정에서 산출된 구조라고 볼 수 있다. 파일은 해당 기능에 의해 Read, Write로 나누는 것이 가능함을 간과하면서 생기는 ISP를 위반한 사례례이다. 인터페이스를 분리함으로써 얻는 이점은 시스템 확장 시에 필요한 기능에 대한 변경이나 확장만으로 변화를 국한 시킬 수 있다는 점과 클래스가 비대해지면서 생기는 트러블(가독성, 높은 결합도에 의한 수정의 어려움)을 예방할 수 있다는 점이다.

 

 

 

<<1-1. 하나의 인터페이스가 두가지 기능을 가지는 경우>>

 

Keypoint

• 클라이언트는 자신이 사용하지 않는 메쏘드에 의존 관계를 맺으면 안된다
• 하나의 일반적인 인터페이스보다는, 여러 개의 구체적인 인터페이스가 낫다

 

 

인터페이스 분리 방법

① 서로 다른 성격의 인터페이스를 명백히 분리할 것.

② 두 개 이상의 인터페이스가 공유하는 부분의 재사용을 극대화할 것

③ 기 구현된 클라이언트의 변경을 주지 말아야 할 것

 

• 객체 인터페이스를 통한 분리

 

<<1-2. 위임을 이용한 객체 인터페이스 분리>>

• 클래스 인터페이스를 통한 분리

 

 

 

 

<<1-3. 하나의 기능에 하나의 인터페이스로 분리한 경우>>

 

ISP를 위반했을 때 생기는 문제점

ISP와 관련한 문제는 대부분 비대해진 클래스로부터 발생하게 된다. 비대해진 클래스는 단지 라인이 많은 클래스를 말하는 것이 아니다. 두개의 짧은 메소드를 갖더라도 원래 클래스가 가져야할 기능 이외의 인터페이스를 가지는 경우는 비대한 클래스로 분류 할 수 있다. 인터페이스를 분리 시키므로써 상속 구조상에서 좀 더 유연한 형태로 개발이 가능하게 할 수 있다.

 

정리

ISP를 지키는 것은 개인적으로 다음에 나오는 OCP, SRP, LSP, DIP와 같은 원칙에 위반하지 않도록 하는 기본이자 관문이라고 생각합니다. 때로는 아무런 메소드도 정의되어 있지 않은 네임스페이스만을 가지는 빈 인터페이스를 정의하는 경우도 종종 있습니다. 객체지향 프로그래밍을 하다보면 특히 C# 계열에서 오신분들은 클래스를 잘게 쪼개는 것을 두려워 합니다. 코드를 따라가기 힘들어서 그러신다는 말도 하시고, 쪼갤 이유가 없어 보인다는 점 때문에 그런다고 하시기도 합니다. 저는 클래스가 정말 단하나의 객체로서 존재할 수 있도록 인터페이스를 설계하는 것이 코드의 가독성을 높이고 전체 적인 구조가 모순이 없도록 구성할 수 있다고 말씀드리고 싶습니다.

 

저도 사실 문제가 없어 보이면 파일수를 줄이는 쪽으로 가려는 경향이 있습니다. 하지만 리팩토링할 때만 되면 제일 먼저 거슬리는 것은 그렇게 내버려 둔 녀석들이 1순위가 되지요. "왜 네놈이 이걸 가지고 있느냐!" 라고 속으로 버럭하고는 한답니다. 원칙은 지킴으로써 그 소임을 다할 수 있다고 생각합니다. 추상화 수준이 높을 수록 클래스의 수명은 늘어납니다.