SOLID — От нуля до картошки 4

Сегодня я объясню принцип разделения интерфейса (ISP), этот принцип очень похож на LSP, поэтому не путайте его с LSP, поэтому я объясню, в чем разница между этими двумя принципами.

LSP управляет отношениями между родительским и дочерним классами (т.е. иерархическими отношениями). Он расскажет вам , как реализовать . ISP регулирует отношения между родительским и клиентским классами (т.е. отношения производитель/потребитель) . Он говорит вам , когда реализовать .

Итак, давайте перейдем к принципу разделения интерфейсов (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) . Удачного кодирования всем вам.

Предыдущая статья о SOLID:

Принцип единой ответственности (SRP) :https:///arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

Открытый/закрытый принцип (OCP): https:///arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

Принцип замены Лисков (LSP): https:///arpalar-tech/solid-from-zero-to-potato-3-94d6f63dbbfe