10장. ISP: 인터페이스 분리 원칙

인터페이스 분리 원칙

• 아래와 같은 UserAction 클래스와 이에 의존하는 클래스 Admin, NormalUser, PremiumUser가 있다고 해보자.

public class UserAction {

    void adminAction(){
        doSomething...
    }

    void normalUserAction(){
        doSomething...
    }

    void premiumUserAction(){
        doSomething...
    }
}

• Admin은 나머지 기능은 사용하지 않지만, 해당 기능들에도 의존하게 된다. 만일 UserAction에서 normal, premium기능이 수정되면 Admin도 컴파일과 배포를 다시 진행해야한다.

public interface AdminAction{
    void adminAction();
}

public interface NormalUserAction{
    void normalUserAction();
}

public interface PremiumUserAction{
    void premiumUserAction();
}

public class UserAction implements AdminAction, NormalUserAction, PremiumUserAction{
    @Override
    public void adminAction() {
    }

    @Override
    public void normalUserAction() {
    }

    @Override
    public void premiumUserAction() {
    }
}

public class Admin{

    private final AdminAction adminAction;
}

public class NormalUser{
    
    private final NormalUserAction normalUserAction;
}

public class PremiumUser{

    private final PremiumUserAction premiumUserAction;
}

• 이런 식으로 각 기능을 분리하면 어떨까?
• Admin은 AdminAction과 adminAction()에는 의존한다. 그러나 UserAction에는 의존하지 않는다. 따라서 만일 AdminAction과 관련 없는 기능이 수정되더라도 별도의 컴파일과 배포 과정을 필요로하지 않는다.

ISP와 언어

• 위의 사례는 언어 타입에 의존한다. 정적 타입 언어는 사용자가 import, use 또는 include와 같은 타입 선언문을 사용하도록 강제한다.
• 이렇듯 소스코드에 선언문이 포함되어 있기 때문에 소스코드 의존성이 발생하고, 이로 인해 재컴파일 또는 재배포가 강제된다.
• 그럼 ISP를 지키기 위해선 정적 언어를 사용하면 안될까? ISP가 비단 언어만의 문제일까?

ISP와 아키텍처

• ISP를 사용하는 근본적인 이유는 정적 언어를 사용하지 않기 위해서가 아니다. 필요 이상으로 많은 것을 포함하고 있는 모듈에 의존하지 않기 위해서다.
• 이는 단일 책임 원칙과 결을 같이 한다. 단일 책임 원칙이 클래스 단위라면, 인터페이스 분리 원칙은 인터페이스 단위인 것이다.
• 소스코드 수준에서 재컴파일과 재배포를 강요하는 것도 지나치게 큰 모듈에 의존하는 것의 단점이지만, 아키텍처 단위에서도 비슷한 문제가 발생한다.
• D 데이터베이스를 사용하는 F 프레임워크를 이용해 S 시스템을 만든다고 해보자. 의존 방향은 S -> F -> D가 될 것이다.
• 즉, S는 D에 의존한다. 그런데, D가 지나치게 많은 기능을 가지고 있어서 F에는 필요없는 기능이 있다면, 이는 결국 S에도 필요없는 기능이 된다.
• 그런데 이 기능 때문에 D 내부가 변경되면, F를 재배포 해야할 수도 있고, 결과적으로 S까지도 재배포가 전파될지 모른다.
• 더 큰 문제는 D가 지닌 기능 중, F와S에 불필요한 기능에 문제가 발생해도 F와S에 영향을 준다는 것이다.

결론

• 불필요하게 많은 기능을 정의하는 무언가에 의존하지 말자. 인터페이스 단위에서도 단일 책임의 원칙은 지켜져야한다.