Manchmal werden wir während des Entwicklungsprozesses feststellen, dass die vom Client und die bereitgestellten Schnittstellen erforderlichen Schnittstellen nicht kompatibel sind. Wir können die Client -Schnittstelle aus besonderen Gründen nicht ändern. In diesem Fall müssen wir uns an vorhandene Schnittstellen und inkompatible Klassen anpassen, für die der Adaptermodus erforderlich ist. Bei Adaptern können wir sie verwenden, ohne den alten Code zu ändern, was die Fähigkeit des Adapters ist.
Der Anpassungsmodus kann verwendet werden, um sich zwischen einer vorhandenen Schnittstelle und einer inkompatiblen Klasse anzupassen. Objekte, die diesen Modus verwenden, werden auch Wrapper bezeichnet, da sie ein anderes Objekt mit einer neuen Schnittstelle einwickeln.
Auf der Oberfläche ähnelt der Adaptermodus dem Aussehensmodus. Sie alle müssen andere Objekte einwickeln und die Schnittstellen ändern, die sie rendern. Der Unterschied zwischen den beiden ist, wie sie die Schnittstelle verändern. Das Erscheinungselement zeigt eine vereinfachte Schnittstelle, die keine zusätzlichen Optionen bietet, und manchmal sind einige Annahmen, um gemeinsame Aufgaben zu erleichtern. Der Adapter wandelt eine Schnittstelle in eine andere um, die bestimmte Funktionen nicht herausfiltert und die Schnittstelle nicht vereinfacht. Wenn die Client -System -API nicht verfügbar ist, ist ein Adapter erforderlich.
Grundtheorie
Adaptermodus: Konvertieren Sie eine Schnittstelle in eine vom Client geforderte Schnittstelle, ohne den Client -Code zu ändern, damit inkompatibler Code zusammenarbeiten kann.
Der Adapter besteht hauptsächlich aus 3 Rollen:
(1) Client: Die Klasse, die die Schnittstelle aufruft
(2) Adapter: Klasse, die zum Verbinden der Client -Schnittstelle und -Corter -Bereitstellung von Diensten verwendet wird
(3) Adapter: bietet Dienste an, ist jedoch mit den Anforderungen der Client -Schnittstelle nicht kompatibel.
Implementierung des Adaptermodus
1. Der einfachste Adapter
Der Adaptermodus ist nicht so kompliziert, wie Sie denken. Lassen Sie uns also das einfachste Beispiel geben.
Der Client ruft eine Methode zur Additionsberechnung auf:
var result = add (1,2);
Wir haben jedoch nicht die Add -Methode bereitgestellt und die Summenmethode mit der gleichen ähnlichen Funktion bereitgestellt:
Funktionsumme (v1, v2) {return v1 + v2;}Um zu vermeiden, dass Client und Server geändert werden, fügen wir eine Wrapper -Funktion hinzu:
Funktion add (v1, v2) {reuTrn sum (v1, v2);}Dies ist der einfachste Adaptermodus. Wir fügen eine Wrapper -Methode zwischen zwei inkompatiblen Schnittstellen hinzu und verwenden diese Methode, um die beiden zu verbinden, damit sie zusammenarbeiten.
2. Praktische Anwendung
Mit der Entwicklung von Front-End-Frameworks haben immer mehr Entwickler begonnen, das MVVM-Framework für die Entwicklung zu verwenden, die nur Daten ohne DOM-Elemente manipulieren müssen, und JQuery hat immer weniger Wirkung. Viele Projekte verweisen weiterhin auf die JQuery Library Tools -Klasse, da wir die von JQuery bereitgestellte AJAX verwenden müssen, um Daten an den Server anzufordern. Wenn Jquerys Rolle im Projekt nur als AJAX -Tool -Bibliothek verwendet wird, ist es so, als wäre es ein bisschen so, als würde man ein Huhn töten und Ressourcenverschwendung verursachen. Zu diesem Zeitpunkt können wir unsere eigene AJAX -Bibliothek vollständig zusammenfassen.
Nehmen wir an, dass der von uns eingekapselte Ajax durch eine Funktion verwendet wird:
ajax ({url: '/getData', Typ: 'post', DataType: 'JSON', Daten: {id: "123"}}). Done (function () {})Mit Ausnahme des Unterschieds zwischen dem Aufrufen der Schnittstelle Ajax und Jquerys $ .Ajax sind die anderen genau gleich.
Es muss viele Orte im Projekt geben, die Ajax anfordern. Wenn wir JQuery ersetzen, können wir $ .ajax nacheinander nicht ändern. Was sollen wir tun? Zu diesem Zeitpunkt können wir einen Adapter hinzufügen:
var $ = {ajax: function (options) {return ajax (option); }}Dies ist mit alten Code und neuen Schnittstellen kompatibel, wodurch Änderungen an vorhandenen Code vermieden werden.
Zusammenfassen
Das Prinzip des Adaptermodus ist sehr einfach. Dies besteht darin, eine neue Wrapper -Klasse hinzuzufügen, um die neue Schnittstelle zu wickeln, um sich an die Anrufe des alten Code anzupassen und die Schnittstelle zu ändern und den Code aufzurufen.
Anwendbare Szenarien: Es gibt viele Code -Anrufe alte Schnittstellen. Um zu vermeiden, dass der alte Code geändert und neue Schnittstellen ersetzt werden, wirken sich die Anwendungsszenarien nicht auf die vorhandenen Implementierungsmethoden aus.
1. Die anwendbaren Anlässe für den Adaptermodus:
Adapter eignen sich für Situationen, in denen die vom Kundensystem erwarteten Schnittstellen mit denen der vorhandenen API nicht kompatibel sind. Die beiden an den Adapter angepassten Methoden sollten ähnliche Aufgaben ausführen, sonst wird das Problem nicht gelöst. Genau wie Brückenelemente und Erscheinungselemente kann durch Erstellen von Adaptern die Abstraktion aus ihren Implementierungen isoliert werden, damit die beiden unabhängig geändert werden können.
2. Vorteile des Adaptermodus:
Wickeln Sie die Schnittstelle einer vorhandenen Klasse mit einer neuen Schnittstelle ein, damit das Kundenprogramm diese Klasse verwenden kann, auf die nicht ohne größere Operation zugeschnitten ist.
3. Nachteile des Orchestrator -Modus:
Einige Leute denken, dass Adapter ein unnötiger Overhead sind, der ausschließlich durch Umschreiben bestehender Code vermieden werden kann. Darüber hinaus führt der Adaptermodus auch eine Reihe neuer Tools ein, die unterstützt werden müssen. Wenn die vorhandene API noch nicht geformt ist oder die neue Schnittstelle noch nicht geformt ist, funktioniert der Adapter möglicherweise nicht immer.
Seine Vorteile tendenziell mehr als ihre Nachteile hervorheben, wenn es um große Systeme und Legacy -Frameworks geht.