SOLID — 0에서 감자까지 4

Apr 02 2023

ISP(인터페이스 분리 원칙) 정보

오늘은 ISP(Interface Segregation Principle)에 대해 설명하겠습니다. 이 원리는 LSP와 매우 유사하므로 LSP와 혼동하지 마십시오. 이 두 원리의 차이점에 대해 설명하겠습니다. LSP는 상위 클래스와 하위 클래스(i.

오늘은 ISP(Interface Segregation Principle)에 대해 설명하겠습니다 . 이 원리는 LSP 와 매우 유사하므로 LSP 와 혼동하지 마십시오 . 이 두 원리의 차이점에 대해 설명하겠습니다.

LSP는 상위 클래스와 하위 클래스 간의 관계(즉, 계층적 관계)를 제어합니다. 구현하는 방법을 알려줍니다 . ISP 는 부모 클래스와 클라이언트 클래스 간의 관계(예: 생산자/소비자 관계)를 관리합니다. 언제 구현해야 하는지 알려줍니다 .

인터페이스 분리 원칙(Interface Segregation Principle, ISP) 이 무엇인지 살펴보겠습니다 . ISP는 일부 클라이언트에 불필요할 수 있는 대규모의 모놀리식 인터페이스를 만드는 대신 특정 클라이언트 또는 클라이언트 집합의 요구 사항에 맞는 인터페이스를 설계해야 한다고 말합니다.

ISP(인터페이스 분리 원칙): 클라이언트는 사용하지 않는 인터페이스에 강제로 의존해서는 안 됩니다.

구현으로 이동하면 StudentActivities학생 활동과 관련된 다양한 메서드를 정의하는 인터페이스가 있습니다.

interface StudentActivities {
    fun joinClub(club: String)
    fun joinSportsTeam(sportsTeam: String)
    fun attendEvent(event: String)
    fun volunteerForEvent(event: String)
    fun joinStudyGroup(subject: String)
}

class Student : StudentActivities {
    override fun joinClub(club: String) {
        // join the specified club
    }

    override fun joinSportsTeam(sportsTeam: String) {
        // join the specified sports team
    }

    override fun attendEvent(event: String) {
        // attend the specified event
    }

    override fun volunteerForEvent(event: String) {
        // volunteer for the specified event
    }

    override fun joinStudyGroup(subject: String) {
        // join the specified study group
    }
}

StudentActivities이제 위의 올바른 예를 리팩토링하여 인터페이스를 클라이언트가 더 쉽게 사용할 수 있는 더 작고 더 집중된 인터페이스로 나눌 수 있습니다 .

interface ClubActivities {
    fun joinClub(club: String)
}

interface SportsActivities {
    fun joinSportsTeam(sportsTeam: String)
}

interface EventActivities {
    fun attendEvent(event: String)
    fun volunteerForEvent(event: String)
}

interface StudyGroupActivities {
    fun joinStudyGroup(subject: String)
}

class Student : ClubActivities, SportsActivities, EventActivities, StudyGroupActivities {
    override fun joinClub(club: String) {
        // join the specified club
    }

    override fun joinSportsTeam(sportsTeam: String) {
        // join the specified sports team
    }

    override fun attendEvent(event: String) {
        // attend the specified event
    }

    override fun volunteerForEvent(event: String) {
        // volunteer for the specified event
    }

    override fun joinStudyGroup(subject: String) {
        // join the specified study group
    }
}

인터페이스에 정의된 활동의 특정 하위 집합 만 필요한 클라이언트는 이제 자신이 사용하지 않는 메서드를 포함하는 더 크고 응집력이 낮은 인터페이스에 의존할 필요 없이 해당하는 더 작은 인터페이스에만 의존할 수 있기 때문에 인터페이스 분리 원칙을 준수 합니다 . 필요하지 않습니다.

이 기사를 읽어 주셔서 감사합니다. 제 글이 유익하고 많은 생각을 하게 하였기를 바랍니다. DIP(Dependency Inversion Principle) 에 대해서는 다음 글에서 설명하겠습니다. 여러분 모두 즐거운 코딩하세요.