Heim >Web-Frontend >js-Tutorial >Vertiefendes Verständnis der JavaScript-Reihe (21): Detaillierte Erläuterung des ISP-Schnittstellenisolationsprinzips der fünf Prinzipien von S.O.L.I.D_Grundkenntnisse
Vorwort
Was wir in diesem Kapitel erklären werden, ist das vierte der fünf Prinzipien der S.O.L.I.D-JavaScript-Sprachimplementierung, das Interface Segregation Principle ISP (The Interface Segregation Principle).
Englischer Originaltext:http://freshbrewedcode.com/derekgreer/2012/01/08/solid-javascript-the-interface-segregation-principle/
Hinweis: Der Autor dieses Artikels ist ziemlich kompliziert, daher ist der Onkel ziemlich deprimiert, wenn er ihn versteht. Lesen Sie ihn einfach und vertiefen Sie sich nicht zu sehr darin
Die Beschreibung des Schnittstellenisolationsprinzips lautet:
Wenn ein Benutzer auf eine Schnittstellenmethode angewiesen ist, die nur von anderen Benutzern, aber nicht von ihm selbst verwendet wird, muss er diese Schnittstellen implementieren. Mit anderen Worten: Ein Benutzer verlässt sich auf eine Schnittstelle, die nicht verwendet wird, sondern von anderen Benutzern verwendet wird Wenn andere Benutzer diese Schnittstelle ändern, sind alle Benutzer betroffen, die darauf angewiesen sind. Dies verstößt offensichtlich gegen das Offen-Geschlossen-Prinzip und entspricht nicht unseren Erwartungen.
Das Schnittstellenisolationsprinzip ISP ähnelt in gewisser Weise der Einzelverantwortung. Beide werden zur Zusammenfassung funktionaler Verantwortlichkeiten verwendet. Tatsächlich kann ISP als Konvertierung eines Programms mit einer einzelnen Verantwortung in ein Objekt mit einer öffentlichen Schnittstelle verstanden werden.
JavaScript-Schnittstelle
Wie können wir dieses Prinzip unter JavaScript einhalten? Schließlich verfügt JavaScript nicht über die Eigenschaften einer Schnittstelle. Wenn es sich bei der Schnittstelle um einen Vertrag handelt, den wir über einen von einer bestimmten Sprache bereitgestellten abstrakten Typ entkoppeln möchten, kann man sagen, dass dies in Ordnung ist, aber JavaScript hat eine andere Form der Schnittstelle. Im Buch Design Patterns – Elemente wiederverwendbarer objektorientierter Software finden wir die Definition der Schnittstelle:
http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612
Jede von einem Objekt deklarierte Operation enthält einen Operationsnamen, ein Parameterobjekt und einen Rückgabewert der Operation. Wir nennen dies die Unterschrift des Betreibers.
Alle in einem Objekt deklarierten Operationen werden als Schnittstelle des Objekts bezeichnet. Die Schnittstelle eines Objekts beschreibt alle Anforderungsinformationen, die an diesem Objekt auftreten.
Unabhängig davon, ob eine Sprache ein separates Konstrukt zur Darstellung einer Schnittstelle bereitstellt, verfügen alle Objekte über eine implizite Schnittstelle, die aus allen Eigenschaften und Methoden des Objekts besteht. Beziehen Sie sich auf den folgenden Code:
exampleBinder.viewAdaptor = (function() {
/* Private Variablen */
Geben Sie {
zurück
bind: function(model) {
/* Code */
}
}
})();
exampleBinder.bind = function(model) {
/* Private Variablen */
BeispielBinder.modelObserver.onChange(/* callback */);
var om = exampleBinder.modelObserver.observe(model);
BeispielBinder.viewAdaptor.bind(om);
Zurück om;
};
Die von der obigen exampleBinder-Klassenbibliothek implementierte Funktion ist eine bidirektionale Bindung. Die von dieser Klassenbibliothek bereitgestellte öffentliche Schnittstelle ist die Bindungsmethode. Die in der Bindung verwendeten Funktionen werden von separaten Objekten wie modelObserver und viewAdaptor implementiert die Methode.
Obwohl JavaScript keinen Schnittstellentyp zur Unterstützung des Vertrags eines Objekts bereitstellt, kann die implizite Schnittstelle des Objekts Programmbenutzern dennoch als Vertrag bereitgestellt werden.
ISP und JavaScript
Einige der Abschnitte, die wir unten besprechen, befassen sich mit den Auswirkungen einer Verletzung des Schnittstellenisolationsprinzips in JavaScript. Wie oben gesehen, ist es schade, das Schnittstellenisolationsprinzip in JavaScript-Programmen zu implementieren, aber es ist nicht so leistungsfähig wie eine statisch typisierte Sprache. Aufgrund der Spracheigenschaften von JavaScript ist die sogenannte Schnittstelle manchmal etwas nicht klebrig.
Erkenntnis des Herbstes
In statisch typisierten Sprachen ist ein Grund für die Verletzung des ISP-Prinzips eine fehlerhafte Implementierung. Alle in Schnittstellen in Java und C# definierten Methoden müssen implementiert werden. Wenn Sie nur einige davon benötigen, müssen auch die anderen Methoden implementiert werden (entweder durch leere Implementierung oder durch Auslösen einer Ausnahme). Wenn Sie in JavaScript nur bestimmte Schnittstellen in einem Objekt benötigen, kann das Problem einer beschädigten Implementierung nicht gelöst werden, obwohl keine Notwendigkeit besteht, die Implementierung der oben genannten Schnittstellen zu erzwingen. Diese Implementierung verstößt jedoch immer noch gegen das Liskov-Substitutionsprinzip.
var GeometryApplication = {
GetLargestRectangle: Funktion(Rechtecke) {
/* Code */
}
};
var DrawingApplication = {
drawRectangles: Funktion(Rechtecke) {
/* Code */
}
};
Wenn ein Rechteckersatz das getLargestRectangle der neuen ObjektgeometrieApplication erfüllt, benötigt er nur die Methode „area()“ des Rechtecks, verstößt jedoch gegen LSP (da er nicht die Methode „Draw“ verwendet, die von der Methode „DrawRectangles“ verwendet werden kann). . ).
Statische Kopplung
Ein weiterer Grund für ISP-Verstöße in statisch typisierten Sprachen ist die statische Kopplung. In statisch typisierten Sprachen spielen Schnittstellen eine wichtige Rolle in einem lose gekoppelten Designprogramm. Unabhängig davon, ob es sich um eine dynamische oder eine statische Sprache handelt, muss ein Objekt manchmal zwischen mehreren Clientbenutzern kommunizieren (z. B. im gemeinsam genutzten Zustand). Für statisch typisierte Sprachen besteht die beste Lösung darin, Rollenschnittstellen zu verwenden, die es Benutzern und Objekten ermöglichen, zu interagieren (). und das Objekt muss möglicherweise mehrere Rollen haben), da seine Implementierung den Benutzer von nicht zusammenhängenden Aktionen entkoppelt. In JavaScript gibt es dieses Problem nicht, da Objekte durch die einzigartigen Vorteile dynamischer Sprachen entkoppelt sind.
Semantische Kopplung
Ein häufiger Grund, der sowohl in dynamischen Sprachen als auch in statisch typisierten Sprachen zu ISP-Verstößen führt, ist die semantische Kopplung. Die sogenannte semantische Kopplung ist die gegenseitige Abhängigkeit, das heißt, das Verhalten eines Objekts hängt von einem anderen Objekt ab , was bedeutet, dass, wenn ein Benutzer eines der Verhaltensweisen ändert, dies wahrscheinlich Auswirkungen auf einen anderen Benutzer hat. Dies verstößt auch gegen das Prinzip der Einzelverantwortung. Dieses Problem kann durch Vererbung und Objektersetzung gelöst werden.
Skalierbarkeit
Ein weiterer Grund für das Problem ist die Skalierbarkeit. Viele Leute geben Beispiele zum Rückruf, um die Skalierbarkeit zu demonstrieren (z. B. Rückrufeinstellungen nach Erfolg in Ajax). Wenn eine solche Schnittstelle eine Implementierung erfordert und das implementierte Objekt viele Vertrautheiten oder Methoden enthält, wird ISP sehr wichtig. Das heißt, wenn eine Schnittstelle zu einer Schnittstelle wird, die viele Methoden implementieren muss, wird ihre Implementierung äußerst komplex Dies kann dazu führen, dass diese Schnittstellen eine nicht klebrige Funktion übernehmen. Dies wird oft als Fettschnittstellen bezeichnet.
Zusammenfassung
Die dynamischen Sprachfunktionen in JavaScript machen unsere Implementierung von nicht-stickigen Schnittstellen weniger einflussreich als statisch typisierte Sprachen, aber das Prinzip der Schnittstellenisolation hat immer noch seinen Platz im JavaScript-Programmiermuster.