인터페이스 분리 원칙(Interface Segregation Principle, ISP)은 로버트 C. 마틴이 제안한 객체 지향 설계의 중요한 원칙 중 하나입니다. 이 원칙은 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 분리해야 한다는 것을 강조합니다. 즉, 하나의 큰 인터페이스보다 여러 개의 작은 인터페이스를 사용하는 것이 바람직하다는 것입니다.
인터페이스 분리 원칙(ISP)은 소프트웨어 설계에서 중요한 원칙으로, 클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않도록 인터페이스를 분리해야 함을 강조합니다. 이를 통해 코드의 유연성과 유지보수성을 높일 수 있으며, 변경의 영향을 최소화할 수 있습니다. ISP를 준수하여 설계하면, 시스템의 복잡도를 줄이고, 각 구성 요소의 역할을 명확하게 하여 보다 견고한 소프트웨어를 개발할 수 있습니다.
ISP의 중요성
- 유연성과 유지보수성 향상:
클라이언트가 자신이 사용하지 않는 메서드에 의존하지 않도록 하면, 인터페이스가 더 유연하고 유지보수하기 쉬워집니다. - 변경의 영향을 최소화:
인터페이스가 잘 분리되어 있으면, 하나의 인터페이스에 변경이 발생해도 다른 인터페이스에는 영향을 미치지 않습니다. - 클래스의 응집도 증가:
작은 인터페이스를 사용하면 클래스가 자신의 책임에 집중할 수 있고, 이는 클래스의 응집도를 높입니다.
ISP를 준수하는 방법
- 기능별로 인터페이스 분리:
인터페이스를 클라이언트가 필요로 하는 기능별로 분리하여 설계합니다. - 인터페이스가 작은 메서드 그룹을 갖도록 설계:
각 인터페이스가 작은 메서드 그룹을 가지도록 설계하여, 클라이언트가 자신이 필요로 하는 기능만 사용할 수 있게 합니다. - 인터페이스 상속을 통해 인터페이스 결합:
필요에 따라 여러 작은 인터페이스를 상속받아 더 큰 인터페이스를 구성할 수도 있습니다.
예시
잘못된 예시:
// 너무 많은 책임을 가진 큰 인터페이스
interface Worker {
void work();
void eat();
}
class HumanWorker implements Worker {
@Override
public void work() {
// 작업하는 코드
}
@Override
public void eat() {
// 식사하는 코드
}
}
class RobotWorker implements Worker {
@Override
public void work() {
// 작업하는 코드
}
@Override
public void eat() {
// 로봇은 먹지 않지만 인터페이스를 구현해야 함
throw new UnsupportedOperationException("로봇은 먹지 않습니다.");
}
}위 예시에서는 Worker 인터페이스가 너무 많은 책임을 가지고 있습니다. RobotWorker 클래스는 eat 메서드를 구현할 필요가 없지만, 인터페이스를 구현해야 하므로 UnsupportedOperationException을 던집니다. 이는 인터페이스 분리 원칙을 위반한 것입니다.
ISP를 준수하는 예시:
// 작업하는 기능을 정의한 인터페이스
interface Workable {
void work();
}
// 식사하는 기능을 정의한 인터페이스
interface Eatable {
void eat();
}
class HumanWorker implements Workable, Eatable {
@Override
public void work() {
// 작업하는 코드
}
@Override
public void eat() {
// 식사하는 코드
}
}
class RobotWorker implements Workable {
@Override
public void work() {
// 작업하는 코드
}
}이 예시에서는 Workable과 Eatable 인터페이스로 기능을 분리했습니다. HumanWorker 클래스는 두 인터페이스를 모두 구현하지만, RobotWorker 클래스는 Workable 인터페이스만 구현하여 필요한 메서드만 제공하게 됩니다. 이렇게 하면 RobotWorker 클래스가 불필요한 메서드를 구현할 필요가 없으며, 인터페이스 분리 원칙을 준수하게 됩니다.
