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

👴 Keep interfaces small so that users don’t end up depending on things they don’t need.

SOLID의 4번째 원칙인 인터페이스 분리 원칙은 인터페이스는 인터페이스를 사용하는 클라이언트 기준으로 분리해야한다 라는 것이다. 인터페이스를 구체적으로 분리해서 자신과 관련없는 메소드는 구현하지 않아야 한다.

ISP를 어기는 경우

인터페이스 분리 원칙을 위반했을 때 발생하는 문제점 중 가장 유명한 예시는 소스 재컴파일 문제이다.

소스 재컴파일

C, C++, Go, Swift, Java는 정적 언어이다. 정적 언어란 변수의 자료형이 컴파일 타임에 결정되는 언어이다. 반대로 동적 언어는 자료형이 런타임에 결정되며 예시로는 Python, Javascript, Ruby 등이 있다. 정적 언어의 경우 한 곳에서의 변경만으로 전체 소스코드를 다시 컴파일해야 한다.

EX1) ISP 위반 예시

(상황 ) 복합기에 print(), copy(), fax() 메소드가 있다. 프린터는 print()를, 복사기는 copy()를, 팩스는 fax()를 사용한다. 세 가지 메소드는 같은 파일에 존재하므로, 프린터의 print()로직만 바뀌어도 복사기와 팩스도 재컴파일을 해야 한다.

👊 인터페이스를 분리해서 해결하자 👊

위와 같은 경우는 인터페이스를 클라이언트 기준으로 나누지 않아서 인터페이스 분리 원칙을 위반하였다. 인터페이스 분리 원칙을 지키려면 인터페이스를 분리하면 된다!! 그럼 인터페이스를 분리하는 기준은? 앞서 말했던 클라이언트를 기준으로 분리하면 된다.

클라이언트는 자신이 사용하는 메소드를 가지는 인터페이스만 구현하도록 한다. 인터페이스를 분리하면 프린터의 print() 로직이 바뀌어도 복사기와 팩스는 영향을 받지 않는다.

결론

인터페이스 분리 원칙은 단일 책임 원칙과도 관련이 있다. 인터페이스 분리 원칙도 한 곳의 변경이 다른 곳에 미치는 영향을 최소화한다. 따라서 클래스가 가지는 책임을 최소화하고 인터페이스를 분리해서 클래스를 설계해야 한다.

REFERENCE
최범균, 「개발자가 반드시 정복해야 할 객체 지향과 디자인 패턴」, 인투북스
Solid Relevance
[소프트웨어 설계] 인터페이스 분리 원칙(ISP-Interface Segregation Principle)