JAVA/ETC

자이구 2023. 12. 13. 15:36

ISP는 '클라이언트는 자신이 사용하지 않는 메서드에 의존 관계를 맺으면 안된다'라는 원칙이다.

SRP를 적용한 예제를 다시 살펴보자.

SRP를 적용한 후에는 밑의 그림과 같이 단일 책임을 갖은 클래스로 나뉘었다.

SRP에서 제시한 해결책은 남자 클래스를 토막내서 하나의 역활만 하는 다수의 클래스로 분할하는 것이었다.

꼭 SRP만 방법일까? 다른 해결책은 없을까?

만약 남자를 토막 내는 것이 너무 잔인하다는 생각이 든다면 그때 선택할 수 있는 방법이 바로 ISP이다.

남자 클래스를 토막 내는 것이 아니라 각자의 상황에 맞게 각각의 역활만 할 수 있게 인터페이스로 제한하는 것이다.

이 것이 바로 인터페이스 분할 원칙이다.

결론적으로 SRP와 ISP는 같은 문제에 대한 두 가지 다른 해결책이라 볼 수 있다.

프로젝트 요구사항과 설계자의 취향에 따라 SRP나 ISP 중 하나를 선택해서 설계할 수 있다.

하지만 특별한 경우가 아니라면 ISP보단 SRP을 적용하는 것이 더 좋은 해결책이라 할 수 있다.

ISP는 SRP와 비슷하게 보이는데, SRP는 클래스 단일 책임을 강조한다면, ISP는 인터페이스 단일 책임을 강조한다.

단, 인터페이스는 클래스와 다르게 추상화이기 때문에 여러개의 역활을 가지는데 있어 제약이 없다.

SRP 원칙의 클래스 책임의 범위에 대해 분리 기준이 다르듯이, 인터페이스를 분리하는 기준은 상황에 따라 다르다.

인터페이스 분할 원칙을 이야기할 때 항상 등장하는 원칙 중 하나로 인터페이스 최소주의 원칙이란 것이다.

인터페이스를 통해 메서드를 외부에 제공할 때는 최소한의 메서드만 제공하라는 것이다.

한가지 예를 들어보자.

상황 : 1.남자가 입대를 하여 소대원이 되었다.

2. 여차친구가 생겼는데 바로 소대장이다.

그럼 인터페이스 최소원칙을 지키지 않았다면 남자친구소대원 인터페이스를 생성할 것이다.

그럼 어떤 복잡한 경우가 생길까?

1. 유격 훈련 중에 소대장에게 키스하는 소대원남자친구

2. 데이트 중 사격하기를 실시하는 소대원남자친구

이런 어처구니 없는 경우를 막기 위해 즉, 훈련 중에는 소대원역활만, 데이트 중에는 남자친구 역활만을 충실히 수행해야한다. 객체 지향 세계에서도 같은 원리가 적용된다.

위의 그림에서 남자친구 인터페이스에 사격하기() 메서드를 제공할 필요도 없고 제공해서도 안된다라는 것이다.

즉, 인터페이스는 그 역활에 충실한 최소한의 기능만 공개하라는 것이다.

인터페이스는 is able to 이라는 기준으로 만드는 것이 정석이라는 것을 꼭 기억하자.

ISP 원칙의 주의해야 할 점은 한번 인터페이스를 분리하여 구성해놓고

나중에 무언가 수정사항이 생겨서 또 인터페이스들을 분리하는 행위를 가하지 말라는 점이다.

이미 구현되어 있는 프로젝트에 또 인터페이스들을 분리한다면, 이미 해당 인터페이스를 구현하고 있는 온갖 클래스들과 이를 사용하고 있는 클라이언트(사용자)에서 문제가 일어날 수 있기 때문이다.

본래 인터페이스라는 건 한번 구성하였으면 왠만해선 변하면 안되는 정책같은 개념이다.

따라서 처음 설계부터 기능의 변화를 생각해두고 인터페이스를 설계해야 하는데, 이는 현실적으로 참 힘든 부분이며 역시 개발자의 역량에 달렸다.

📖Reference