[OOP] SOLID 원칙 - ISP(인터페이스분리원칙)

ISP (Interface Segregation Priciple) - 인터페이스분리원칙

• 클라이언트는 사용하지 않는 인터페이스에 의존을 강요당해서는 안된다.
• 클라이언트를 기준으로 인터페이스를 분리하라는 뜻이다.
• 클라이언트 : 인터페이스를 사용하는 프로그래밍 요소인데, 보통 인터페이스를 구현하는 클래스를 의미한다.
• 객체지향 프로그래밍 특징 중 '캡슐화'에 해당되는 것 같다. (+ 모듈화)

---

💫 ISP 위반 예시

interface Vehicle {
    fun start()
    fun stop()
    fun accelerate()
    fun brake()
    fun openDoor()
    fun closeDoor()
    fun turnOnHeadlights()
    fun turnOffHeadlights()
}

• 인터페이스에 너무 많은 메서드가 포함되어있어 유지 및 보수가 어렵다.
• 인터페이스는 클라이언트가 사용하지 않는 메서드에 의존하지 않도록 분리되어야한다.

💫 ISP 예시

interface Drivable {
    fun start()
    fun stop()
    fun accelerate()
    fun brake()
}

interface Openable {
    fun openDoor()
    fun closeDoor()
    // 문 열고 닫기
}

interface Lightable {
    fun turnOnHeadlights()
    fun turnOffHeadlights()
    // 라이트 켜고 끄기
}

class Car : Drivable, Openable, Lightable {
    override fun start() {
    }

    override fun stop() {
    }

    override fun accelerate() {
    }

    override fun brake() {
    }

    override fun openDoor() {
    }

    override fun closeDoor() {
    }

    override fun turnOnHeadlights() {
    }

    override fun turnOffHeadlights() {
    }
}

fun main() {
    val car = Car()
    car.start()
    car.accelerate()
    car.openDoor()
    car.turnOnHeadlights()
    }

💫 ISP를 지키기 위해 지양해야할 점

🪐안정된 소프트웨어 아키텍처를 위해서는 변동성이 큰 구현체에 의존하는 일을 지양하고, 안정된 추상 인터페이스를 사용하는 것이 좋다. 구현체에 의존하는 인터페이스는 ISP 원칙을 위반할 수 있기 때문이다.
🪐 ISP 원칙은 인터페이스에 대한 단일 책임을 강조하는 설계원칙이므로 인터페이스에 대한 단일 책임을 지향하지 않는다면 ISP 원칙을 위반하게 된다.
🪐 너무 큰 인터페이스를 만들게 되면 클라이언트가 사용하지 않는 메서드에 의존하게 되어 ISP 원칙을 위반하게 된다.

---

참고한 블로그

• https://cbs5295.medium.com/oop-solid-%EC%9B%90%EC%B9%994-isp-interface-segregation-principle-553152b9145b