Ich weiß, diese Frage wurde oft gestellt, aber ich habe etwas recherchiert und verstehe es immer noch nicht, wahrscheinlich können Sie mir helfen: Wie bereits mehrfach erwähnt, ist die UML fast identisch. Auch die Implementierung und Idee ist mehr oder weniger die gleiche: Anstatt Sub-Typisierung, definieren Sie eine Schnittstelle, die einige Logik kapselt und es an eine Zusammenfassung übergeben. Also, auch die Microsoft-Blog Jungs
Ссылка sagt:
Die einfache Antwort lautet: "Sie sind ähnlich, aber anders". Das Implementierungen sind ähnlich, aber die Absichten sind unterschiedlich. Geben eine Analogie, ein Stadtbus und Schulbus sind beide ähnliche Fahrzeuge, aber Sie werden für verschiedene Zwecke verwendet. Einer wird verwendet, um Menschen zu transportieren zwischen verschiedenen Teilen der Stadt als Pendlerdienst. Der Andere ist verwendet für den Transport von Kindern zu Schulen.
"Wenn es wie eine Ente klingt und wie eine Ente aussieht, aber es beabsichtigt, ein Schwan zu sein, kann es beides sein", was ich hier lese.
Da ich es immer noch nicht verstanden habe, habe ich tiefer gegraben:
Dieser Thread fügt auch nichts neues hinzu, außer:
Sie sehen für mich auch beide auf der Oberfläche gleich aus. Die Hauptsache Unterschied, den ich sehe, ist die Tatsache, dass in der Brücke Muster, die Abstraktion ist Teil des Objekts, aber in der Strategie Muster der Abstraktion wird durch das Objekt durchgeführt.
Aber wenn wir die Definition der Strategie lesen:
Definieren Sie eine Familie von Algorithmen, kapseln Sie sie ein und machen Sie sie austauschbar. Strategie lässt den Algorithmus unabhängig von variieren Clients, die es verwenden.
Es ist nicht festgelegt, wie die Strategie angewendet wird. Es könnte auch leicht eine Schnittstelle zum Abstract sein, genau die gleiche Strategie-Implementierung wie LINQ-Orderby etc.
Ein weiteres Interesse für das Thema ist hier:
Der Hauptteil von diesem Vorteil:
Sie sagen "Strategie", wenn Sie das Verhalten ändern möchten, und Sie tun dies nicht indem Sie verschiedene Objekte schreiben, aber eine Klassenhierarchie einführen. Sie sagen Sie "Bridge", wenn Sie erwarten, dass Sie sowohl die Schnittstelle und variieren die Umsetzung. In beiden Fällen bieten Sie Flexibilität für ein Änderung der Implementierung; in einer Brücke erwartest du auch die Schnittstelle zu ändern.
Ist das wahrscheinlich der Hauptunterschied? Da der Implementor und die Abstraktion so locker gekoppelt sind, kann ich die Schnittstelle des Implementors ändern und muss sich die Abstraktion nicht kümmern? Das klingt vernünftig, aber würde sich die Abstraktion auch nicht ändern, da sie irgendwie miteinander verbunden sind? Würde das nicht alle anderen Prinzipien wie Information Hiding und DRY zerstören?
Ich habe mir auch viele Beispiele angesehen, die ich hier nicht wegen des Ortes hinzufüge, und ich konnte kein Beispiel für eines dieser Muster finden, das ich nicht ändern konnte, um es dem anderen anzupassen. Sei es über eine Interface-Eigenschaft oder nur einen Parameter.
Hab ich hier irgendwas verpasst? Hat wahrscheinlich jemand ein REAL-LIFE-Beispiel von "Ich wollte die Strategie verwenden, aber die Brücke passte einfach besser", oder umgekehrt, Beispiel?
Bearbeiten: Warum begründe ich (wieder) einen eigenen Thread für dieses Thema? Zunächst einmal ist die angenommene Antwort des erwähnten Threads die folgende
Wie ich es verstehe, verwenden Sie das Strategie-Muster, wenn Sie es sind abstrahierendes Verhalten, das von einer externen Quelle bereitgestellt werden könnte (zB. config könnte angeben, dass eine Plugin-Assembly geladen werden soll) Verwenden des Brückemusters, wenn Sie die gleichen Konstrukte verwenden, um Ihre zu erstellen Code ein bisschen sauberer. Der tatsächliche Code wird sich sehr ähnlich sehen - du bist nur die Muster aus etwas anderen Gründen anwenden.
Ich habe bereits in den vorangegangenen Ausführungen dargelegt, dass abstrahierendes Verhalten von externer Quelle genau die Definition von Strategie- und Bridge-Pattern ist.
Auch
und Sie verwenden das Brückenmuster, wenn Sie dieselben Konstrukte verwenden um Ihren Code ein wenig sauberer zu machen.
Auch das Strategie-Pattern macht den Code etwas übersichtlicher, da er einen ganzen Baustein weg abstrahiert und somit den Code ein wenig aufwertet.
Ich denke jeder, der das ganze Thema gelesen hat, sieht, dass es zu diesem Thema mehr gibt als nur diese zwei Sätze.
Wikipedia UML-Diagramm für Brückenmuster :
Sehen Sie sich meine Antwort in der verknüpften Frage für grundlegende Unterschiede an:
Was? ist der Unterschied zwischen dem Brückenmuster und dem Strategiemuster?
Hauptunterschied: Abstraktion und Implementierung können sich unabhängig voneinander ändern .
Bezüglich Ihrer anderen Fragen:
Ist das wahrscheinlich der Hauptunterschied? Da der Implementor und die Abstraktion so locker gekoppelt sind, kann ich die Schnittstelle des Implementors ändern und muss sich die Abstraktion nicht kümmern? Das klingt vernünftig, aber würde sich die Abstraktion auch nicht ändern, da sie irgendwie miteinander verbunden sind?
Sehen Sie sich das Codebeispiel @
anWann verwenden Sie das Brückenmuster? Wie unterscheidet es sich von Adapter-Muster?
Obwohl das Beispiel in Java ist, kann es für c # Entwickler leicht verstanden werden.
Im verlinkten Beispiel:
%Vor%Keynotes:
Jetzt können Vehicle
und GearShifter
unabhängig voneinander geändert werden.
Wenn sich Vehicle
ändert, müssen nur Car
und Truck
geändert werden.
Wenn sich GearShifter
ändert, müssen nur ManualGearShifter
und AutoGearShifter
geändert werden.
Da Vehicle
(Abstraktion) GearShifter
(Implementierung) über Komposition enthält, wirken sich Änderungen in GearShifter
nicht auf Vehicle
Da GearShifter
(implementor) Vehicle
(Abstraktion) nicht enthält oder verweist, wirken sich Änderungen in der Abstraktion nicht auf die Implementierung aus.
BEARBEITEN:
Das Brückenmuster stellt zwei orthogonale Klassenhierarchien dar - Eins steht für Abstraktion und eins für Implementor , das unabhängig ohne Abhängigkeit von anderen geändert werden kann.
Ich habe das ursprüngliche Entwurfsmusterbuch beide Abstraktions- und Implementationshierarchien sich unabhängig voneinander ändern können (d. H. Neue Unterklassen können für eine Abstraktion eingeführt werden; neue Unterklassen können für Implementierungen eingeführt werden). Ihr Beispiel behandelt eine Fensterbibliothek, die für verschiedene Fenstersysteme funktionieren kann. Im ursprünglichen Beispiel verwendeten die Autoren ein anderes Fenstersystem von IBM, aber ich glaube, eine gute aktuelle Analogie wären verschiedene Linux-Fenstermanager (GNOME, KDE usw.). Stellen Sie sich eine Windows-Abstraktion und zwei Implementierungen für GNOME und KDE vor. Und nun stellen Sie sich vor, dass Sie die neue Window-Unterklasse TransparentWindow hinzufügen möchten. TransparentWindow erweitert Window, so wie GNOMEWindow und KDEWindow. Sie müssen aber auch TransparentWindow erstellen: GNOMETransparentWindow und KDETransparentWindow. Die Hierarchie sieht unordentlich aus. Stellen Sie sich einen neuen Fenstertyp oder einen neuen Fenstermanager vor - XFCE. Um komplizierte Hierarchien zu vermeiden, führen sie das Brückenmuster ein und trennen zwei Hierarchien (d. H. TransparentWindow erweitert Window; GNOMEWindow und KDEWindow erweitern WindowImpl). Für mich scheint es ein schwieriger Teil zu sein, die Schnittstelle für die Implementierung zu definieren, da die Hierarchien der Abstraktionen ihre Operationen nur mit dieser Schnittstelle definieren müssen. Ein Beispiel für ein Bridge-Muster, das mir gefallen hat, ist hier , und ich mochte es, weil es keine künstlichen Klassen ConcreteImplementor1 verwendet und ConcreteImplementor2. Wenn es um reale Beispiele geht, glaube ich, dass ich dieses Muster in der Implementierung von Selenium WebDriver gesehen habe, aber ich bin mir jetzt nicht 100% ig sicher.
Tags und Links c# design-patterns oop strategy-pattern bridge