Wenn ich etwas Neues lernen will, frage ich mich, was ich verloren habe, wenn ich dieses Ding nicht lerne. Ich werde einige Designmuster lernen und alles ist gut. Aber als ich in Bridge Design Pattern ankam, fiel mir das Problem auf. Wirklich kann ich mir nicht vorstellen, wann man dieses Entwurfsmuster verwendet. Und ich weiß, dass es einen anderen Link in Google und Stackoverflow gibt, wie dies .
Aber kann jemand sagen, was wir verloren haben, wenn wir Bridge Design Pattern
vergessen und dieses Muster ausprobieren?
Das Brückenmuster bemerkt einfach ein paar konvergierende Verantwortlichkeiten und trennt sie. Ich werde das Beispiel von The Gang of Four (TGF) benutzen, weil ich denke, dass es ein wirklich guter ist:
Sie haben eine Window-Schnittstelle mit zwei Unterklassen: XWindow (basierend auf dem X Window Manager) und PMWindow (basierend auf dem Presentation Manager (PM) Window Manager von IBM ... von dem ich noch nie gehört habe).
>ie:
%Vor%Das Problem bei der Fortsetzung unseres traditionellen Vererbungsansatzes besteht darin, dass Sie, wenn Sie Fenster auf einen anderen Aspekt als seine Plattformabhängigkeit spezialisieren (dh Sie haben eine gewisse Verantwortung, die orthogonal zu der von Ihnen erstellten Vererbungsstruktur ist), benötigen Um das Brückenmuster zu verwenden, wird Ihre Klassenhierarchie geometrisch in der Tiefe wachsen. Ich denke, ein guter Weg, um Bridge als eine Kombination aus Vererbung und Komposition zu denken.
Das ist ziemlich wortreich. Zurück zum TGF-Beispiel: Was ist, wenn Sie ein IconWindow und ein TransientWindow (so etwas wie eine Glasscheibe) wollen. Das Konzept von "Icon vs Transient" und "PM vs X" sind zwei orthogonale Ideen, aber beide versuchen, in den gleichen Vererbungsbaum zu gelangen. Wenn Sie das Brückenmuster nicht verwenden, müssen Sie zwei neue Schnittstellen erstellen, die von der ersten abstammen, und eine Reihe von Klassen darunter:
%Vor%Mit dem Brückenmuster würden Sie diese beiden Verantwortlichkeiten auf zwei Vererbungsbäume aufteilen:
%Vor%Viel sauberer, viel bessere Verantwortungstrennung und viel einfacher zu schreiben und zu konsumieren!
Ich glaube , dass dieses Designproblem und die Merkwürdigkeiten sogar des Brückenobjektbaums tatsächlich einige der Probleme waren, die das Design von Mix-ins in Scala antreiben. Mit der Mehrfachvererbung von C ++ würden Sie alle Implementierungen statisch an ihr Fenstersystem koppeln. Mit anderen Worten, Sie hätten die gleiche Anzahl von Typen wie das Nicht-Brücken-Muster, aber sie wären wahrscheinlich leere Klassen, und Sie können natürlich durch die Abstraktion auf sie verweisen, was es ziemlich einfach macht, sie zu konsumieren.
>Die Vorteile einer Brücke sind, dass Abstraktion und Implementierung entkoppelt sind. Die Implementierung wird zur Laufzeit auch dynamisch geändert und die Erweiterbarkeit von Abstraktion und Implementierung wird verbessert.
Durch Angabe eines Parameters bei der Generierung einer Abstraktion kann die Implementierung auch für die Implementierung des Clients vollständig ausgeblendet werden. Ein starker Anstieg der Anzahl der Klassen kann vermieden werden.
Tags und Links java c# php asp.net design-patterns