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

인터페이스는 그 인터페이스를 사용하는 클라이언트를 기준으로 분리해야 한다.

즉, 클라이언트는 자신이 사용하는 메서드에만 의존해야 한다.

인터페이스 변경과 그 영향

C++ 로 게시판 모듈을 개발한다고 해보자. ArticleService 클래스의 기능은 아래와 같다.

• 게시글 작성

• 게시글 목록

• 게시글 삭제

기능에 대한 인터페이스 명세는 ArticleService.h 헤더 파일에 작성되고, 구현은 ArticleService.cpp 파일에 코딩될 것이다. 그리고 해당 클래스를 사용하는 코드는 #include를 이용해서 ArticleService.h 에 정의된 타입 정보를 이용해 코드를 작성할 것이다.

위의 그림과 같이 각 UI를 기준으로 개발 파트를 나누고 구현이 이루어 진다고 하면, 최종 실행 파일을 만들기 위해 다음과 같은 과정을 거치게 된다. 각각의 UI와 ArticleService.cpp을 컴파일한 결과 오브젝트 파일을 만들어 내고, 그 오브젝트 파일들을 링크하게 된다.

ArticleService 클래스의 목록 읽기 기능과 관련된 멤버 함수의 시그니처에 변경이 발생했다고 하자.

이 경우 ArticleService.h 헤더 파일과 ArticleService.cpp 파일에 변경을 반영한 뒤에 컴파일해서 ArticleService.o 오브젝트 파일을 생성할 것이다. 그리고 게시글 목록 기능에 변경이 발생했으므로, 게시글 목록 UI 소스를 변경한 뒤에 컴파일해서 게시글 목록 UI 오브젝트 파일을 생성할 것이다.

그러나 변경은 여기서 끝나지 않는다. ArticleService.h 파일이 변경되었기 때문에 이 헤더 파일을 사용하는 게시글 작성 UI와 게시글 삭제 UI의 소스 코드도 다시 컴파일해서 오브젝트 파일을 만들어 주어야 한다.

결국, 게시글 작성 UI와 게시글 삭제 UI와 상관없는 게시글 목록 기능에 변경이 발생했음에도 불구하고 소스 코드를 다시 컴파일한 것이다.

인터페이스 분리 원칙은 자신이 사용하는 메서드에만 의존해야 한다는 원칙인데, 앞서 C++ 개발한 게시글 관리 프로그램 예제는 인터페이스 분리 원칙을 위반했다.

인터페이스 분리 원칙

ArticleService 클래스는 게시글 목록/작성/삭제에 대한 모든 메서드를 제공하고 있으며, 각 UI 코드는 ArticleService.h 헤더 파일에 의존하고 있다.

이로 인해 ArticleService 클래스의 한 메서드의 시그니처 변경에 따라, ArticleService.h 헤더 파일을 사용하는 모든 코드는 재컴파일해야 하는 상황이 발생한 것이다.

따라서, 위와 같이 ArticleService 인터페이스를 각 클라이언트가 필요로 하는 인터페이스들로 분리함으로써, 각 클라이언트가 사용하지 않는 인터페이스에 변경이 발생하더라도 영향을 받지 않도록 만들어야 한다.

게시글 쓰기 UI는 ArticleWriterService 인터페이스에 의존하고 있다. 따라서 ArticleListService.h 인터페이스에 변경이 발생하더라도 게시글 목록 UI만 영향을 받을 뿐 게시글 쓰기 UI나 게시글 삭제 UI를 다시 컴파일하지 않아도 된다.

자바 언어를 사용하고 있다면 컴파일을 통해 .class 파일을 생성하면 될 뿐, 링크 과정을 수행하지 않는다. 실제 링크 과정은 자바 가상 머신(JVM)이 .class 파일을 로딩하는 과정에서 동적으로 발생되기 때문에 개발자가 각 클래스 파일들을 연결하는 링크 과정을 직접해 줄 필요가 없는 것이다. 따라서 자바 언어에서는 위의 문제가 발생하진 않는다.

용도에 맞게 인터페이스를 분리하는 것은 단일 책임 원칙과도 연결된다.

단일 책임 원칙에서 봤듯이 하나의 타입에 여러 기능이 섞여 있을 경우, 한 기능의 변화로 인해 다른 기능이 영향을 받을 가능성이 높아진다.

따라서, 클라이언트 입장에서 사용하는 기능만 제공하도록 인터페이스 분리함으로써 한 기능에 대한 변경의 여파을 최소화할 수 있게 된다.

또한, 단일 책임 원칙이 잘 지켜질 때 인터페이스와 콘크리트 클래스의 재사용 가능성이 높일 수 있으므로, 인터페이스 분리 원칙은 결국 인터페이스와 콘크리트 클래스의 재사용성을 높여 주는 효과도 갖는다.

인터페이스 분리 원칙은 클라이언트에 대한 것

인터페이스 분리 원칙은 클라이언트 입장에서 인터페이스를 분리하라는 원칙이다.

'의존의 양면성'을 통해, ArticleService 인터페이스의 변화가 게시글 목록 UI에 영향을 주지만, 반대로 게시글 목록 UI의 요구로 인해 ArticleService 인터페이스가 변경될 수 있다.

의존의 양면성

A가 B를 의존할 경우,

B의 변화로 인해 A가 변경되지만, 반대로 A의 요구에 의해 B가 변경될 수 있다.

이는 인터페이스 분리의 기준이 클라이언트가 된다는 것을 알 수 있다.

각 클라이언트가 사용하는 기능을 중심으로 인터페이스를 분리함으로써, 클라이언트로 부터 발생하는 인터페이스 변경 요의 여파가 다른 클라이언트에 미치는 영향을 최소화할 수 있게 된다.