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

해당 내용에서는 인터페이스 분리의 원칙을 구현하는 가장 좋은 시기와 방법에 대한 내용을 담았습니다.

지난 시간에는 리스코프 치환의 원칙에 대하여 설명했었습니다. 이번 시간에는 인터페이스 분리의 원칙을 이야기해보려 합니다. 인터페이스 분리의 원칙에서의 기본은 클라이언트가 사용하지 않는 메소드에 대한 강제가 있어서는 안된다는 것입니다.

많은 메서드가 있는 인터페이스와 해당 메서드 중 일부만 정상적으로 사용되고 있지만 많은 클래스가 이 인터페이스를 구현한다고 가정해 보겠습니다.

---

Athlete 인터페이스는 운동선수의 일부 동작이 있는 인터페이스입니다.

package com.blackdog.solid.segragation;

public interface Athlete {
    void compete();
    void swim();
    void highJump();
    void longJump();
}

compete 메소드를 추가했지만, swim, highJump, longJump와 같은 메소드 또한 존재하고 있습니다.

저 흑구가 수영 선수라고 가정해보겠습니다. Athlete 인터페이스를 구현하게 된다면 수영선수인 흑구가 사용하지도 않을 highJump, longJump 메소드를 구현해야만 합니다.

package com.blackdog.solid.segragation;

public class Blackdog implements Athlete {

    @Override
    public void compete() {
        System.out.println("흑구가 시합을 합니다.");
    }

    @Override
    public void swim() {
        System.out.println("흑구가 수영을 합니다.");
    }

    @Override
    public void highJump() {
    }

    @Override
    public void longJump() {
    }
}

만일 높이뛰기, 멀리뛰기 선수의 경우도 불필요한 swim 메소드를 구현해야함으로써 같은 문제가 발생합니다. 따라서 이를 해결하도록 인터페이스 분리의 원칙을 따라 리팩토링 해보겠습니다.

---

기존 Athlete 인터페이스를 아래와 같이 수정합니다.

package com.blackdog.solid.segragation;

public interface Athlete {
    void compete();
}

그 다음 두개의 인터페이스를 더 설계합니다. 하나는 수영과 관련된 인터페이스(SwimmingAthlete) 또 다른 하나는 뛰기와 관련된 인터페이스(JumpingAthlete) 입니다.

public interface SwimmingAthlete extends Athlete { // 수영과 관련된 운동 인터페이스
    void swim();
}

public interface JumpingAthlete extends Athlete { // 뛰기와 관련된 운동 인터페이스
    void highJump();
    void longJump();
}

따라서 Blackdog 클래스는 구현하지 않아도 될 메소드들을 구현하지 않도록 할 수 있습니다.

public class Blackdog implements SwimmingAthlete {

    @Override
    public void compete() {
        System.out.println("흑구가 시합을 합니다.");
    }

    @Override
    public void swim() {
        System.out.println("흑구가 수영을 합니다.");
    }

}

Swim과 관련된 기능을 인터페이스로 분리함으로써 불필요한 Jump 관련 기능의 구현을 강제하지 않도록 변경하였습니다.