it-swarm.com.de

"Abhängig von Abstraktionen, nicht von Konkretionen", was ist die genaue Bedeutung dieses Begriffs

Ich habe SOLID Prinzipien auf einer Website gelesen, in der für D - Abhängigkeitsinversionsprinzip es sagt:

"Hängen Sie von Abstraktionen ab, nicht von Konkretionen"

Mit anderen Worten. Wir sollten unsere Software so gestalten, dass verschiedene Module mithilfe einer abstrakten Ebene voneinander getrennt werden können, um sie miteinander zu verbinden.

Beispiel für ein Prinzip der Abhängigkeitsinversion

Die klassische Verwendung dieses Prinzips der Bohnenkonfiguration im Spring-Framework.

Im Spring Framework werden alle Module als separate Komponenten bereitgestellt, die durch einfach eingefügte Abhängigkeiten in anderen Modulen zusammenarbeiten können. Diese Abhängigkeit wird extern in XML-Dateien verwaltet.

Diese separaten Komponenten sind in ihren Grenzen so gut geschlossen, dass wir sie mit Ausnahme der Feder problemlos in anderen Softwaremodulen verwenden können. Dies wurde durch Abhängigkeitsinversion und offene geschlossene Prinzipien erreicht. Alle Module stellen die einzige Abstraktion bereit, die zum Erweitern der Funktionalität oder des Plug-Ins in einem anderen Modul nützlich ist.

Ich habe ein paar Fragen dazu.

  • Abhängig von Abstraktionen, nicht von Konkretionen Es bedeutet, Codierung auf Schnittstellen, nicht auf konkrete Klassen?
  • Warum wird Spring Bean Beispiel gegeben? Ja, wir können Schnittstellen verwenden, um die Abhängigkeit einzufügen. Aber können wir auch eine konkrete Klasse einspritzen?
8
kulsin

Abhängig von Abstraktionen, nicht von Konkretionen Bedeutet es, auf Schnittstellen zu codieren, nicht auf konkrete Klassen?

Bei Sprachen, die Schnittstellen unterstützen, ist dies im Allgemeinen der Fall. Diese Abstraktionsschicht kann jedoch auch auf andere Weise bereitgestellt werden, z. B. durch eine abstrakte Klasse, eine Fabrik, eine Reflexion usw. Wichtig ist, dass Sie eine Anforderung nicht direkt an eine benannte, konkrete Klasse koppeln.

* Warum wird ein Beispiel für eine Frühlingsbohne gegeben? Ja, wir können Schnittstellen verwenden, um die Abhängigkeit einzufügen. Aber können wir auch eine konkrete Klasse einspritzen?

Vermutlich, weil Sie "SOLID Principles in Java " (Hervorhebung von mir) betrachten. Spring ist ein beliebtes DI-Framework für Java. " Aber wir können auch eine konkrete Klasse injizieren ?" Sie injizieren immer eine konkrete Klasse. Welche konkrete Klasse wird jedoch von Ihrer Federkonfiguration bestimmt? Der Empfänger der Injektion hängt nur von einer Abstraktion ab, nicht von dieser spezifischen Klasse. Wenn etwas anderes sagt, welche konkrete Implementierung verwendet werden soll, ist dies die Essenz von DI.

8
David Arno

Abhängig von Abstraktionen, nicht von Konkretionen.
Es bedeutet, auf Schnittstellen zu codieren, nicht auf konkrete Klassen?

Wird auch als "Codierung der Schnittstelle (nicht zu verwechseln mit interface dem Schlüsselwort), nicht der Implementierung" bezeichnet.
Es ist eine alte Technik namens Abstraktion. Jede Abstraktionsebene versucht, irrelevante Details zu verbergen und so die Komplexität zu verringern, sodass größere und weniger fehleranfällige Systeme erstellt werden können. Die Kosten sind, dass sowohl das Verstecken als auch das Nichtausnutzen der Details selbst oft Kosten verursachen.

Es hat nichts mit Klassen, Funktionen, Konstanten oder was auch immer zu tun. Es bedeutet einfach nur abhängig vom Vertrag das Versprechen, das die Implementierung einhalten muss, wenn sie als fehlerhaft bezeichnet wird, anstatt mit "arbeitet für mich" zu arbeiten (jetzt, hier, während niemand hinschaut).

Warum wird Spring Bean Beispiel gegeben? Ja, wir können Schnittstellen verwenden, um die Abhängigkeit einzufügen. Aber können wir auch eine konkrete Klasse einspritzen?

Das Dependency Inversion Principle (DIP) hängt stark davon ab, da es das Ersetzen verschiedener Implementierungen einfach macht, sogar erwartet.

Der Grund, warum ein prominentes Java Framework) verwendet wird, ist einfach, dass Ihre Quelle mit Java funktioniert.

Ob Sie ein class oder ein interface injizieren, spielt für DIP keine Rolle, aber interfaces sind die Hintertür zu MI in Java und enthalten nur minimal hartcodiertes Verhalten und keine Daten.

6
Deduplicator

Abstraktion bedeutet nicht unbedingt eine Schnittstelle. Wenn Sie an zwei interagierende Komponenten denken, während sich der Code weiterentwickelt, werden sich Dinge ändern, aber es wird Aspekte geben, die mehr oder weniger gleich bleiben. Änderungen an einer Komponente führen jedoch im Allgemeinen zu Änderungen an der anderen abhängigen Komponente.

Wenn Sie jene Aspekte erkennen, die sich nicht ändern oder die die wesentlichen Merkmale der Interaktion bilden, "extrahieren" Sie sie in eine Abstraktion - eine Sache, die Ausdruck dieser Aspekte ist: könnte eine Schnittstelle, eine konkrete oder abstrakte Basis sein Klasse, die vererbt werden kann, eine Datenstruktur, eine Reihe von zusammenarbeitenden Klassen usw. Aber es geht nicht darum nur eine Schnittstelle dazwischen hinzuzufügen - das ist nur zusätzlicher Code; Die Benutzeroberfläche muss eine gut gestaltete Verallgemeinerung sein, die aussagekräftig genug ist, um die meisten Fälle abzudecken, ohne dass sie geändert wird (zu häufig - bis sie sich stabilisiert). Es ist also nicht unbedingt einfach, das Richtige zu finden.

Sobald Sie dies getan haben, schreiben Sie beide Komponenten in Bezug auf diese Abstraktion neu (was Sie als "Codierung in Schnittstellen" bezeichnet haben) - normalerweise ruft eine Seite die Abstraktion auf, die andere stellt einen Dienst hinter der Abstraktion bereit, um dies sicherzustellen den durch die Abstraktion definierten "Vertrag" einhalten.

Wenn Sie in Ihrem eigenen Code eine Komponente A haben, die von B abhängt, müssen Sie möglicherweise warten, bis mehrere verschiedene Varianten von B auftauchen, bevor Sie herausfinden, was allen gemeinsam ist, und diese in eine Schnittstelle oder eine andere Art herausziehen einer Abstraktion. Oder Sie wissen genug über die Problemdomäne, um zu erraten, wie eine gute Abstraktion aussehen würde.

1