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

특징

• 자신이 사용하지 않는 메서드에 의존하지 않아야 한다는 원칙입니다.
• 하나의 큰 인터페이스보다 세부적인 여러개의 인터페이스로 나눠서 설계해야한다는 원칙입니다.
• 이를 통해 인터페이스 간의 결합도를 낮추고 필요로 하는 기능만을 사용할 수 있게 됩니다.

 

Bad Case

public interface MonsterBehavior {
    void attack();
    void move();
    void drop();
}

public static class AttackMonster implements MonsterBehavior{

        @Override
        public void attack() {

        }

        @Override
        public void move() {

        }

        @Override
        public void drop() {

        }
    }

    public static class NoAttackMonster implements MonsterBehavior{

        @Override
        public void attack() {

        }

        @Override
        public void move() {

        }

        @Override
        public void drop() {

        }
    }

 

Good Case

public interface AttackBehavior {
    void attack();
}

public abstract class AbstractMonster {

    public abstract void move();

    public abstract void drop();

}

public static class AttackMonster extends AbstractMonster implements AttackBehavior {
    @Override
    public void attack() {
    }

    @Override
    public void move() {
    }

    @Override
    public void drop() {
    }
}

public static class NoAttackMonster extends AbstractMonster {
    @Override
    public void move() {
    }

    @Override
    public void drop() {
    }
}

 

Why?

BadCase에서 NoAttackMonster 클래스는 attack() 메서드가 필요 없음에도 MonsterBehavior 인터페이스의 모든 메서드를 구현해야 합니다. 이는 불필요한 의존성을 초래하며, 인터페이스의 목적과는 거리가 먼 구현을 강제합니다.

 

Good Case는 각 몬스터의 행동을 더 세밀하게 제어할 수 있게 해 줍니다. AttackMonster는 공격 기능이 필요하므로 AttackBehavior 인터페이스를 구현하고, NoAttackMonster는 이 기능을 제외하고 필요한 행동만을 구현합니다. 이는 각 클래스가 필요로 하는 인터페이스에만 의존하도록 함으로써 결합도를 낮추고, 각 클래스의 역할을 명확히 합니다.

 

결론적으로 ISP를 통해 우리는 클라이언트(여기서는 몬스터 클래스)가 실제로 필요하지 않은 메서드에 의존하지 않도록 보장합니다. 이는 코드의 가독성을 향상시키고, 유지 관리를 용이하게 하며, 확장성을 증가시킵니다. 또한, 필요한 기능만을 제공함으로써 시스템 전반의 복잡성을 줄이는데 기여합니다.