Inhaltsverzeichnis
Dies ist der vierte Teil einer Reihe von Tutorials, die sich auf die Überprüfung der grundlegenden Themen der Java-Sprache konzentrieren, um den Leser auf die Verwendung des Spring Frameworks vorzubereiten. Der erste Teil dieser Tutorial-Reihe ist hier erhältlich, der zweite Teil hier und der dritte Teil hier. In diesem Tutorial sehen wir 2 grundlegende Konzepte, die wir behandeln müssen, wenn wir Spring korrekt verwenden wollen: Inversion of Control und Dependency Injection.Zunächst möchte ich klarstellen, dass diese Konzepte von Martin Fowler in diesem Artikel viel besser erklärt und auf dieser Seite ins Spanische übersetzt werden, aber meine Absicht ist es, das Konzept zusammenzufassen, um es leicht verständlich zu machen und Ihnen ein wenig das Lesen zu ersparen Artikel (obwohl Sie herzlich eingeladen sind, ihn zu lesen, wenn Sie weitere Fragen haben).
Der Begriff ist relativ neu, aber es ist ein Programmiermuster, das auf Programme zurückgeht, die mit rein sequentieller Programmierung erstellt wurden, bei denen sich ein einzelner Programmierer (oder eine Gruppe von Programmierern) zusammensetzte, um eine Reihe von Schritten oder Rechenanweisungen zu schreiben, die perfekt ausgeführt werden sollten von Anfang bis Ende mit der Absicht, ein letztes Ergebnis zu erzielen.
Zu diesem Zeitpunkt (glauben Sie nicht, dass es viele Jahre her ist) kamen die Aufrufe der Methoden und Bibliotheken immer von einer zentralen Quelle, die für die Manipulation aller Variablen im selben Programm verantwortlich war. Später wurden grafische Oberflächen entwickelt, die für die Verwaltung der Dateneingaben in das Programm verantwortlich waren, während der Hauptfluss des Programms dafür verantwortlich war, Handler für die Ereignisse bereitzustellen, die in der grafischen Oberfläche aufgetreten sind (aktiviert etwas beim Klicken, Drücken dieser Taste , Bewegen der Maus usw.), während sich die Schnittstelle in einer Dauerschleife befindet. Auf diese Weise wird die Kontrolle des Programms umgekehrt, die grafische Benutzeroberfläche ist dafür verantwortlich, den Hauptfluss darüber zu informieren, was und wie zu tun ist, ohne genau wissen zu müssen, WIE es gemacht wird.
Wenn Sie bemerken, können Schnittstellen in Java Ihnen helfen, die Kontrolle über eine Anwendung an externe Agenten zu übertragen, aber das Konzept ist auf Daemon-Threads anwendbar, die darauf warten, dass ein Ereignis eintritt, um ausgelöst zu werden, eine Klasse, die für die Instanziierung und Bereitstellung von Implementierungen anderer Klassen verantwortlich ist das Programm (Werksmuster) und im Wesentlichen jedes Muster, das es ermöglicht, die Kontrolle über das Programm an einen externen Agenten zu übertragen.
Es ist eine besondere Art der Inversion of Control, bei der eine Klasse A zum Zeitpunkt der Kompilierung nicht weiß, welches Objekt sie verwenden wird, sondern nur die Aktionen, die sie mit diesem Objekt ausführen muss. Nehmen wir die folgende Klasse an (die auf den Klassen basiert, die in meinem vorherigen Tutorial erstellt wurden):
öffentliche Klasse Zeichner {öffentlicher Platz; öffentlicher Cartoonist () {Quadrat = neues Quadrat (); } public void MasterDraw () {square.Draw (); }} Wie Sie sehen werden, hängt diese "Draftsman"-Klasse vollständig von der "Square"-Klasse ab, da sie für den Lebenszyklus des quadratischen Objekts verantwortlich ist, das sie später verwenden wird. Diese Art, eine "Draftsman"-Klasse zu erstellen, ist sehr unpraktisch, denn wenn wir später möchten, dass der Draftsman Rechtecke oder Dreiecke zeichnet, müssten wir den Basiscode ändern, um dies zu tun.
Stattdessen können wir eine wiederverwendbarere Klasse erstellen, wenn wir die "Drawable" -Schnittstelle implementieren, die wir im vorherigen Tutorial erstellt haben:
öffentliche Klasse Zeichner {öffentliche Drawable Drawing; öffentlicher Zeichner (Drawable d) {Zeichnung = d; } public void MasterDrawing () {drawing.Drawing (); }} Auf diese Weise "steuern" die Objekte der Klasse "Draftsman" nicht das Objekt, das sie zeichnen müssen, sondern wissen nur, dass es die Drawable-Schnittstelle implementiert und später diese "Draftsman"-Objekte, die ich in meiner Anwendung erstellen werde oder jemandem else in einer Anwendung verwendet werden soll, die auf meine Objektbibliothek zugreift, sind sie perfekt in der Lage, jedes Objekt zu empfangen, das die "Drawable"-Schnittstelle implementiert.
Im vorherigen Beispiel wenden wir das an, was als bekannt ist "Konstruktor-Injektion" da die Abhängigkeit auf Konstruktorebene eingefügt wird, aber Sie können die Abhängigkeit auch über die "Setter" einfügen oder in anderen Programmiersprachen die Parameter oder die Schnittstellen einfügen (In Java können Sie die Parameter oder die Schnittstellen nicht ändern, die akzeptieren eine Methode zur Laufzeit, aber Python beispielsweise ermöglicht es Methoden, Parameter zu akzeptieren, ohne den Typ der Parameter anzugeben.)
öffentliche Klasse Zeichner {öffentliche Drawable Drawing; public void setDrawing (Drawable d) {drawing = d; } public void MasterDrawing () {drawing.Drawing (); }} Das Abhängigkeitsspritze ermöglicht im Wesentlichen eine Trennung der Funktionalitäten Ihres Programms. Diese Unabhängigkeit ermöglicht es Ihnen, Ihre Klassen zu testen, ohne dass Ihre Klasse an irgendetwas gebunden ist (es lohnt sich zu wiederholen). Diese Unabhängigkeit ist eines der Schlüsselelemente, die es zu nutzen gilt Feder, die Komponenten vom Framework und nicht von der Anwendung abhängen, können Sie Objekte erstellen, die außerhalb Ihrer Anwendung vorhanden sind, und diese nur dann verwenden, wenn Sie sie benötigen.
Ab dem nächsten Tutorial beginnen wir direkt mit Spring zu arbeiten und Sie werden sehen, wie alle Konzepte, die wir bisher gesehen haben, mit der Bedienung zusammenhängen und es Ihnen ermöglichen, sich in kurzer Zeit das erforderliche Fachwissen anzueignen.
Ich erwarte Ihre Kommentare, bis zum nächsten Mal!Hat dir dieses Tutorial gefallen und geholfen?Sie können den Autor belohnen, indem Sie diesen Knopf drücken, um ihm einen positiven Punkt zu geben
