[Java] 인터페이스 분리 원칙 (Interface Segregation Principle, ISP)

안녕하세요. 성조입니다.

 

SOLID의 4 번째 원칙. ISP에 대해 정리해 보려 합니다.

혹여나 올바르지 못한 지식 전달이 있는 경우 언제든지 피드백 댓글 남겨주시면 감사드리겠습니다.

---

인터페이스 분리 원칙(Interface Segregation Principle, ISP)이란?

인터페이스 분리 원칙은 '클라이언트가 사용하지 않을 불편한 메서드를 강제적으로 구현하게 해서는 안 되는 것이다.'이다.

즉, 클라이언트는 사용하지 않는 메서드에 의존하지 않아야 한다는 얘기이다.

 

조금 더 설명하면 A, B, C라는 메뉴가 있다.

고객은 A 음식만 원하는데 A를 먹기 위해서는 B와 C를 반드시 먹어야 하는 것이다. 이런 경우 인터페이스 분리 원칙이 적용되지 않았다고 얘기할 수 있다.

메뉴판에 있는 A, B, C에서 A만 먹고 싶다면 A만 주문할 수 있게 해주는 것을 인터페이스 분리 원칙이라 한다.

 

 

[인터페이스 분리 원칙(ISP)이 적용되지 않은 예시]

interface Workable {
    void canCook();
    void canClean();
    void canPaint();
}

class Worker implements Workable {
    @Override
    public void canCook() {
        System.out.println("Cooking...");
    }

    @Override
    public void canClean() {
        System.out.println("Cleaning...");
    }

    @Override
    public void canPaint() {
        System.out.println("Painting...");
    }
}

class Chef implements Workable {
    @Override
    public void canCook() {
        System.out.println("Cooking...");
    }

    @Override
    public void canClean() {
        // 이 방법이 필요로 하지 않아도 강제로 구현해야 한다.
    }

    @Override
    public void canPaint() {
        // 이 방법이 필요로 하지 않아도 강제로 구현해야 한다.
    }
}

위 코드는 workable 인터페이스에 존재하는 메서드를 모두 구현해야 사용할 수 있다.

 

[인터페이스 분리 원칙(ISP)이 적용된 예시]

interface Cookable {
    void canCook();
}

interface Cleanable {
    void canClean();
}

interface Paintable {
    void canPaint();
}

class Worker implements Cookable, Cleanable, Paintable {
    @Override
    public void canCook() {
        System.out.println("Cooking...");
    }

    @Override
    public void canClean() {
        System.out.println("Cleaning...");
    }

    @Override
    public void canPaint() {
        System.out.println("Painting...");
    }
}

class Chef implements Cookable {
    @Override
    public void canCook() {
        System.out.println("Cooking...");
    }
}

위 코드는 원하는 인터페이스가 분리되어 존재하기 때문에 원하는 객체에서 값을 호출하여 활용할 수 있게 된 코드이다. 

 

 

인터페이스 분리 원칙(Interface Segreation Principle, ISP) 장점과 단점

[장점]

1. 모듈 간의 느슨한 결합

인터페이스를 분리하는 과정에서 각 클래스는 필요한 인터페이스에게만 의존하게 되기 때문에 모듈 간의 결합도가 낮아진다. 결합도가 낮아지면서 시스템의 유연성과 확장성이 증가하게 되는 장점이 있다.

 

2. 재사용성과 유지 보수성 향상

각 인터페이스는 자신의 책임에 집중할 수 있게 되므로, 다른 부분에서 SOLID의 O인 개방-폐쇄 원칙을 통하여 인터페이스가 필요할 때 쉽게 재사용할 수 있게 된다. 또한, 각 인터페이스와 이를 구현한 클래스가 명확한 책임을 분배하므로 유지 보수의 장점이 존재한다.

 

3. 변경에 대한 구분

각 클래스는 자신이 필요로 하는 기능만을 가진 인터페이스를 구현하기 때문에, 한 인터페이스에 대한 변경이 그 인터페이스를 사용하는 클래스에만 영향을 준다. 이는 변경에 대한 영향을 최소화하는 데 도움 되는 장점이 있다.

 

 

[단점]

1. 설계 및 개발 시간 증가

각 클래스가 필요로 하는 기능에 맞게 인터페이스를 세분화하려면 설계 초기 단계에서 많은 노력과 시간이 필요해진다. 규모에 따라서 설계가 다르게 측정될 텐데 만드는 과정에서 고려할 것이 많아져서 개발 시간이 많이 늘어날 수 있다는 얘기다.

 

2. 과도한 인터페이스 분리

필요 이상으로 인터페이스를 세분화하는 경우. 인터페이스의 수가 과도하게 증가하여 오히려 복잡성이 증가하고, 이해하거나 관리하는 것이 어려워질 수 있다.

 

다른 SOLID 원칙들도 대부분 단점에서 오버 엔지니어링이 발생할 수 있는 점이 있다. 설계하고 만들어낼 때. 오버 엔지니어링이 발생하지 않도록 주의하면서 만드는 것이 좋을 것 같다.

---

오타나 궁금한 부분이 있다면 언제든지 댓글 남겨주시면 답변드릴 수 있도록 노력하겠습니다.

 

다음 포스팅 때 뵙겠습니다. 감사합니다.