SRP(단일 책임 원칙) vs ISP(인터페이스 분리 원칙)

[leeys9423]

💡 이슈

SRP(단일 책임 원칙) vs ISP(인터페이스 분리 원칙)

❓ 이유

책에서 단일 책임 원칙(SRP)과 인터페이스 분할 원칙(ISP)은 같은 문제에 대한 두 가지 다른 해결책이라고 볼 수 있다고 합니다.

그렇다면 어떠한 상황에 단일 책임 원칙을 사용해 문제를 해결하고 어떠한 상황에서 인터페이스 분할 원칙을 사용해 문제를 해결하는게 좋을까요?

[Cupcakes33]

제가 생각하기에 두 원칙의 핵심 의제가 다르다고 생각하는데요,
SRP 의 의제는 '이 클래스의 변경 사유가 오직 하나인가?' 이고,
ISP 의 의제는 '클라이언트가 알아야 할 것들 이외에 다른걸 알고있지는 않은가?' 라고 생각해요.
각각 SRP 는 물리적으로 클래스를 분할하고
ISP 는 인터페이스만 분리한다는 느낌이죠.
설계자와 클라이언트의 관점으로 나누어서 보면 조금 더 쉽게 생각할 수 있을 것 같습니다.

저는 SRP 를 생각해볼 때는 '책임이 섞여있을 때' 에요.
클래스 내부의 변수나 메서드가 공통된 하나의 책임이 아니라 여러개의 책임을 같이 가지고 있어서 따로 논다거나,
변경의 이유가 제각기 다를때죠 ?
SRP 는 아마 많이 적용해보셨을거고 적용 사유가 명확해서 따로 예시를 들지는 않겠습니다.

ISP 는 클래스의 기능 자체가 논리적으로는 묶여있을 수 있지만, '사용하는 대상의 목적이 서로 다를 때' 고려합니다.
이건 사용해야 하는 상황이 잘 떠오르진 않는데..
뭐 예를들어서, 큰 하나의 인터페이스를 구현체 A와 구현체 B가 의존하고 있을 때
구현체 A는 인터페이스의 특정 기능만 사용하고 구현체 B는 인터페이스의 또 다른 기능만 사용하고 있다면
나누는게 맞겠죠 ? 구체적인 예시를 한번 들어볼까요 ?
스마트폰을 사용할 때, 전화 앱과 카메라 앱이 있다고 가정해볼게요.
스마트폰 이라는 클래스는 전화기능, 카메라기능, 인터넷기능이 모두 필요한 클래스 입니다.
그런데 전화 앱과 카메라 앱은 각각 전화기능과 카메라기능만 사용하게 될거에요.
여기서 전화 앱과 카메라 앱을 클라이언트 라고 생각해보는거에요.
그러면 스마트폰 클래스를 그대로 두고 Callable, Camerable 같은 인터페이스를 만들어서
해당 앱은 이 인터페이스에 의존하게 만들면 좋지 않을까요 ?

불필요한 의존성을 끊어내는 것 이라는 공통의 목표를 다른 방식으로 해결하는 방법 이라고 책에서 설명하지만,
사실 '불필요한 의존성' 이라는 단어도 위에서 설명한 스마트폰 예시 처럼
구현체 내부의 물리적인 의존과 구현체 외부의 참조 의존을 구분해서 생각해보면 좋을 것 같습니다.

[yslee-dev]

정성스러운 글 정말 감사합니다!!
다만 제 질문의 의도를 조금 더 명확히 설명드리고 싶어요.

책의 내용을 보시면, SRP를 처음 설명할 때 '남자' 예제가 나옵니다!

처음에는 남자 클래스 안에 남자친구, 군인, 아들의 책임이 모두 섞여있었고, 이를 공통 속성/행동은 남자 클래스에 남기고, 각 역할별 클래스를 상속으로 분리하여 단일 책임 원칙으로 해결했습니다.

그런데 책에서는 같은 예제를 인터페이스로도 해결하는 방식을 보여줍니다!!

남자친구 인터페이스, 군인 인터페이스, 아들 인터페이스를 각각 명세하고, 클라이언트는 필요한 역할을 조합 (예: 남자친구이면서 군인인 클래스)

제가 물어본 것은 "같은 문제를 인터페이스와 클래스/메서드 중 어떤 상황에서 어느 것을 선택하는 게 최선일까?" 였던거 같네요.
(다시 생각해보니 결국 상속 vs 컴포지션 인터페이스 구현에 대한 질문으로 수정해야겠네요.)

[Cupcakes33]

상속과 컴포지션으로 들어가면 아예 다른문제가 될 것 같은데요? ㅋㅋㅋㅋㅋㅋㅋㅋ
책에서 나온 저 남자친구, 군인, 아들의 책임 분리는 그 객체의 정체성에 초점을 맞추느냐, 역할에 초점을 맞추느냐에 있다고 봐요.
그런 관점에서, 남차진구인 영섭님과 군인인 영섭님은 같은 객체이지만 다른 역할을 나타내어야 하죠 ?
그러면 저는 인터페이스로 쪼개는게 좋을 것 같슴니다.

[yslee-dev]

아 말을 또 잘못했네요...
컴포지션이 아니라 인터페이스 구현이라고 생각해주세요ㅠㅠ....

말씀해주신 부분이 매우 공감이 갑니다. 주호님의 말씀에 한마디 더 붙여본다면, 역할이 하나만 필요하고 앞으로도 추가될 가능성이 없다면 상속도 괜찮아 보입니다.

여기서 조금 더 나아가 보자면 두 개를 함께 쓰는 경우도 생각해볼까요? 쉽게 컬렉션 프레임워크를 한번 떠올려보시죠!

public class ArrayList<E> 
    extends AbstractList<E>              // 상속: 공통 구현
    implements List<E>, RandomAccess,    // 인터페이스: 역할들
               Cloneable, Serializable

AbstractList 상속: 리스트의 공통 동작(공통 속성/메서드)
여러 인터페이스 구현: List(리스트 역할), RandomAccess(빠른 접근 가능), Serializable(직렬화 가능) 등의 다양한 역할

이렇게 정체성은 상속으로, 역할은 인터페이스로 나누어 설계하면 두 가지 장점을 모두 가져갈 수 있는 것 같습니다.