SOLIDO — Dallo zero alla patata 5

Oggi continuerò a spiegare il principio di inversione delle dipendenze (DIP) in questo articolo. Avremo familiarità con altri principi in SOLID perché anche se non conosciamo il principio SOLID possiamo imparare dal codice del nostro senior, vari articoli di supporto e tutorial, ma sarà molto raro sentire cos'è Dependency Inversion e come dovremmo usarlo e perché dovremmo usarlo.

A proposito, se lavori già come Android Developer non confondere con Dependency Injection. Conoscerai già le librerie popolari Dagger, Hilt e Koin. Questi due sono molto diversi quindi fai attenzione quando spieghi soprattutto nelle interviste.

Dependency Injection è una tecnica di implementazione per popolare le variabili di istanza di una classe. Dependency Inversion è una linea guida generale di progettazione che raccomanda che le classi abbiano solo relazioni dirette con astrazioni di alto livello.

Principio di inversione delle dipendenze (DIP): i moduli di alto livello non dovrebbero dipendere da moduli di basso livello; entrambi dovrebbero dipendere da astrazioni.

Lascia che ti spieghi con una semplice implementazione del codice, dopodiché capirai meglio DIP. Come al solito iniziamo con Studentuna classe che ha una dipendenza da una Teacherclasse per eseguire alcune funzionalità:

class Student(private val teacher: Teacher) {
    fun askQuestion(question: String) {
        teacher.answerQuestion(question)
    }
}

quindi lascia che refactor aderisca al DIP , possiamo introdurre un'astrazione tra le classi Studente Teacher:

interface QuestionAnswerer {
    fun answerQuestion(question: String)
}

class Teacher : QuestionAnswerer {
    override fun answerQuestion(question: String) {
        // answer the specified question
    }
}

class Student(private val questionAnswerer: QuestionAnswerer) {
    fun askQuestion(question: String) {
        questionAnswerer.answerQuestion(question)
    }
}

Questo aderisce al DIP perché la Studentclasse ora dipende da un'astrazione ( QuestionAnswerer) piuttosto che da un'implementazione concreta ( Teacher). Ciò consente una maggiore flessibilità ed estensibilità, poiché qualsiasi classe che implementa l' QuestionAnswererinterfaccia può essere utilizzata come dipendenza per la Studentclasse, non solo per la Teacherclasse.

Dopo aver visto la versione con refactoring, spero che capirai perché dovremmo usare anche Dependency Inversion , DIP aiuta a disaccoppiare i componenti nella tua applicazione e può rendere il tuo codice più flessibile, gestibile e più facile da testare.

Grazie per aver dedicato del tempo a leggere questo articolo. Spero che la mia scrittura sia stata informativa e stimolante. Buon codice per tutti voi allora prima.

Articolo precedente su SOLIDO :

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

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

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

Principio di segregazione dell'interfaccia (ISP):https://medium.com/arpalar-tech/solid-from-zero-to-potato-4-d1d9b42c3a78