SOLID – Von Null bis Potato 5

Apr 02 2023
Über das Prinzip der Abhängigkeitsinversion (DIP) in diesem Artikel wird dies der letzte Artikel über SOLID sein.
Heute werde ich in diesem Artikel weiter das Prinzip der Abhängigkeitsinversion (DIP) erklären. Wir werden mit anderen Prinzipien in SOLID vertraut sein, denn selbst wenn wir das SOLID-Prinzip nicht kennen, können wir aus dem Code unseres Seniors, verschiedenen mittleren Artikeln und Tutorials lernen. aber Sie werden sehr selten hören, was Dependency Inversion ist und wie wir es verwenden sollten und warum wir es verwenden sollten.

Heute werde ich in diesem Artikel weiter das Prinzip der Abhängigkeitsinversion (DIP) erklären. Wir werden mit anderen Prinzipien in SOLID vertraut sein, denn selbst wenn wir das SOLID- Prinzip nicht kennen , können wir aus dem Code unseres Seniors, verschiedenen mittleren Artikeln und Tutorials lernen. aber Sie werden sehr selten hören, was Dependency Inversion ist und wie wir es verwenden sollten und warum wir es verwenden sollten.

Übrigens, wenn Sie bereits als Android-Entwickler arbeiten, verwechseln Sie dies nicht mit Dependency Injection. Sie werden bereits mit den beliebten Bibliotheken Dagger, Hilt und Koin vertraut sein. Diese beiden sind sehr unterschiedlich, seien Sie also vorsichtig, wenn Sie dies besonders in Interviews erklären.

Dependency Injection ist eine Implementierungstechnik zum Füllen von Instanzvariablen einer Klasse. Abhängigkeitsinversion ist eine allgemeine Entwurfsrichtlinie, die empfiehlt, dass Klassen nur direkte Beziehungen zu Abstraktionen auf hoher Ebene haben sollten.

Dependency Inversion Principle (DIP): High-Level-Module sollten nicht von Low-Level-Modulen abhängen; beide sollten von Abstraktionen abhängen.

Lassen Sie mich Ihnen die einfache Codeimplementierung erklären, danach werden Sie DIP besser verstehen. Beginnen wir wie üblich mit Studenteiner Klasse, die eine Abhängigkeit von einer TeacherKlasse hat, um einige Funktionen auszuführen:

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

Lassen Sie also umgestalten, um sich an das DIP zu halten, wir können eine Abstraktion zwischen den Klassen Studentund einführen :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)
    }
}

Dies entspricht dem DIP, da die Klasse jetzt von einer Abstraktion ( ) und nicht mehr von einer konkreten Implementierung ( ) Studentabhängt . Dies ermöglicht eine größere Flexibilität und Erweiterbarkeit, da jede Klasse, die die Schnittstelle implementiert, als Abhängigkeit für die Klasse verwendet werden kann, nicht nur für die Klasse.QuestionAnswererTeacherQuestionAnswererStudentTeacher

Nachdem Sie die überarbeitete Version gesehen haben, werden Sie hoffentlich verstehen, warum wir auch die Abhängigkeitsumkehr verwenden sollten. DIP hilft dabei , die Komponenten in Ihrer Anwendung zu entkoppeln, und kann Ihren Code flexibler, wartbarer und einfacher zu testen machen.

Vielen Dank, dass Sie sich die Zeit genommen haben, diesen Artikel zu lesen. Ich hoffe, dass mein Schreiben informativ und zum Nachdenken anregend war. Viel Spaß beim Programmieren für euch alle.

Vorheriger Artikel über SOLID :

Single-Responsibility-Prinzip (SRP) :https:///arpalar-tech/solid-from-zero-to-potato-e7b5cfe8c7a1

Open/Closed-Prinzip (OCP): https:///arpalar-tech/solid-from-zero-to-potato-2-5a4c17bd8ec8

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

Prinzip der Schnittstellentrennung (ISP):https:///arpalar-tech/solid-from-zero-to-potato-4-d1d9b42c3a78