SOLIDO — Dallo zero alla patata 4

Oggi spiegherò il principio di segregazione dell'interfaccia (ISP), questo principio è molto simile a LSP, quindi non confondere con LSP, quindi spiegherò cosa c'è di diverso tra questi due principi.

LSP governa le relazioni tra classi genitore e figlio (cioè relazioni gerarchiche). Ti dice come implementare . L' ISP governa le relazioni tra le classi genitore e cliente (cioè le relazioni produttore/consumatore). Ti dice quando implementare .

Quindi spostiamo ciò che è il principio di segregazione dell'interfaccia (ISP), l'ISP afferma che dovremmo progettare interfacce specifiche per le esigenze di un particolare cliente o insieme di clienti, piuttosto che creare interfacce monolitiche di grandi dimensioni che potrebbero non essere necessarie per alcuni clienti.

Principio di segregazione dell'interfaccia (ISP): un client non dovrebbe essere costretto a dipendere da interfacce che non utilizza.

Passiamo all'implementazione, abbiamo un'interfaccia chiamata StudentActivitiesche definisce vari metodi relativi alle attività degli studenti:

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
    }
}

Consentire ora il refactoring all'esempio precedente corretto, possiamo suddividere l' StudentActivitiesinterfaccia in interfacce più piccole e più mirate che sono più facili da utilizzare per i client:

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
    }
}

Ciò aderisce al principio di segregazione dell'interfaccia perché i client che necessitano solo di un sottoinsieme specifico delle attività definite nelle interfacce possono ora dipendere solo dall'interfaccia più piccola corrispondente, piuttosto che dover dipendere da un'interfaccia più grande e meno coesa che contiene metodi che non t bisogno.

Grazie per aver dedicato del tempo a leggere questo articolo. Spero che la mia scrittura sia stata informativa e stimolante. Spiegherò il principio di inversione della dipendenza (DIP) nel prossimo articolo. Buon Coding a tutti voi.

Articolo precedente su SOLIDO :

Principio di responsabilità unica (SRP) :https:///arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

Principio aperto/chiuso (OCP): https:///arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

Principio di sostituzione di Liskov (LSP): https:///arpalar-tech/solid-from-zero-to-potato-3-94d6f63dbbfe