Zitat von
ice.icewing:
Ich habe mir gestern noch einmal die Grundlagen angeschaut und erneut ein Beispiel für ein Brückenmuster programmiert und an diesen Beitrag angehängt. Leider habe ich im Internet immer nur Primitivbeispiele gefunden und hoffe das zum einen mein Beispiel ein Brückenmuster korrekt darstellt und zukünftig vielleicht auch dem einen oder anderen weiter hilft.
Hi,
bitte versteh mich nicht falsch, an deinem Beispiel möchte ich dann doch etwas Kritik üben. Das erste was mir aufgefallen ist ist, dass leider wenig Kommentiert wurde. Natürlich hast Du hier die einzelnen Elemente benannt, es wäre aber deutlich schöner, wenn Du ein paar Erklärende Worte dazu schreibst. Du sagst selbst, dass Du gerne jmd. helfen würdest, diesem jmd. würde es aber ggf. doch weiter helfen, wenn er nicht alle Beiträge im Thread lesen muss um den Ansatz in deiner Implementierung zu verstehen.
Wichtig wäre (
imho), dass Du kurz erläuterst, worum es in dem Beispiel geht. Natürlich musst Du nicht nochmal das Brückenmuster erklären, aber darauf verweisen wäre schon nicht schlecht. Wie der Name ja vorweg nimmt handelt es sich um ein Muster. Die Entwurfsmuster heißen ja nicht zu Unrecht so. Das heißt natürlich auch, dass man die Bestandteile und deren Verhalten in der Implementierung wiederfindet. Erstere hast Du noch benannt (Abstraktion, konkrete Abstraktion,..) aber das Verhalten bleibt unkommentiert.
Nun ja, bei Beispielen muss ich sagen ist es natürlich auch immer schöner, wenn Du die Benennung sinnvoll wählst. Das gilt dann für die Namen der Units, die Variablen und auch die (visuellen) Komponenten und deren Caption. Das eigentliche Brückmuster kannst Du zudem natürlich auch von der Anzeige auf dem Formular trennen. Nicht falsch verstehen, ist halt nur so, dass es gerade bei Beispielen immer toll ist, wenn jmd. gutes Vorbild ist, hat aber auch weniger mit dem eigentlichen Problem zu tun.
Zitat von
ice.icewing:
Daher frage ich jetzt: Ist das Brückenmuster überhaupt für eine variable
DBMS-Anbindung geeignet oder sollte ich auf der Anwendungsseite lieber auf Unabhängigkeit verzichten und einen Adapter nutzen, wobei ich auch hier nicht sicher bin in wie weit das möglich ist.
Nun ja, hier musst Du klar zwischen einfach, zeit-aufwendig und geeignet differenzieren. Geeignet ist es auf jeden Fall, denn genau das Problem (Abstrahieren von etwas Konkretem an mehr als einer Stelle) ist das Brückenmuster gedacht.
Vorallem ist die Umsetzung des Brückenmusters mit einem gewissen zeitlichen Aufwand verbunden, das ist aber immer der Fall, wenn Du sauber modellieren möchtest. Dabei sollte hier aber auch klar gesagt werden, dass eine schlechte/unvollständige Modellierung später deutlich mehr Zeit kostet, als man hier bei der Planung investiert.
Dann wäre da noch der Punkt der Einfachheit. An sich hängt hier natürlich viel von der konkreten Umsetzung ab. Dennoch lassen sich Komplexe Probleme immer in einfachere Teilprobleme zerlegen. Führt man dies weiter fort, so erreicht man irgendwann den Punkt sehr einfacher Probleme, die sich zudem auch einfach lösen lassen. Beziehst Du also Einfachheit auf die Komplexität des Codes, so würde ich Dir generell dazu raten, immer möglichst einfachen Code zu verwenden, was aber wieder ein Thema für sich ist.
An sich bleibt natürlich weiterhin die Frage, ob sich für Dich das Brückenmuster lohnt oder nicht. Dabei solltest Du aber berücksichtigen, dass Du hier ein Front- und Back-End hast, dass Du in vielen unterschiedlichen Projekten verwenden kannst. Die so erstellte Lösung ist (wenn gut modelliert) recht abstrakt und wäre damit nicht auf bestimmte DBMSe beschränkt, auch eine
XML-basierte oder sonstige Dateisystem-basierte Lösung wäre z.B. denkbar (z.B. bei lokalem Export oder so).
An sich setzen natürlich auch existierende Delphi-Lösungen auf das Brücken-Muster. Nimm hier einfach TDataset und die verschiedenen konkreten Ausprägungen auf der einen Seite und der Zugriff auf ein DMBS über
BDE,
ADO usw. auf der Anderen. Da wird im Prinzip nichts anderes gemacht.
Bei einer eigenen Umsetzung hast Du allerdings eine höhere Flexibilität und mehr Einfluss auf die Umsetzung. Ggf. kannst Du hier mehr Leistung aus spezielleren Umsetzungen rausholen. Vorallem kannst Du einfach auf Änderungen an einem
DBMS reagieren (bessere Treiber, neue Eigenschaften, ...). Nicht immer werden solche Änderungen auch für eine bestimmte, vorhandene Abstraktion von Borland übernommen. Andererseits bist Du natürlich mit einer eigenen Lösung auf eigene Anpassungen angewiesen.
Als Alternative (und vielleicht guter Anfang) bietet sich zudem noch die Kombination mit dem Adapter-Muster an. Du kannst natürlich Dein eigenes Interface erstellen und einen Adapter als eine konkrete Implementierung verwenden, die auf etwas wie TDataset zurückgreift. Hier entsteht natürlich erstmal unnötiger Overhead, den Du nicht benötigst. Da dies aber nur eine mögliche Abstraktion ist, ermöglicht sie Dir die Arbeit mit deiner Schnittstelle (hier kannst Du schauen, wie gut Deine Planung war), gleichzeitig kannst Du aber auch nach und nach weitere Alternativen schaffen, die vielleicht durch den Verzicht auf andere Abstraktionen und gezielteren Anpassungen sogar perfomanter arbeiten als bestehende Lösungen.
Das Brückenmuster bleibt dabei der einfache Zusammenhang, dass Du zwei Seiten hast, die eine gewisse Abstraktion darstellen und verschieden implementiert werden. Um es nochmal deutlich zu machen möchte ich hier auf ein schönes Beispiel, dass sich auch bei Wikipedia findet zurückgreifen:
Zitat:
(nicht wörtlich zitiert, nur sinngemäß!)
Eine Abstraktion sind Autos. Es gibt ganz unterschiedliche Arten von Autos, da wäre z.B. ein Merced SLK 500, ein BMW M6, und ein VW-Golf. Ist klar, dass das alles ganz unterschiedliche Autos sind (man könnte da natürlich noch weiter verfeinern, aber egal).
Auf der anderen Seite hätten wir Straßen. Da gibt es u.A. Autobahnen und Landstraßen. Ein beliebiges Auto muss jetzt so entworfen werden, dass es auf jeder Straße fährt, das ist alles.
Ich denke das gibt ganz gut die eigentliche Idee des Brücken-Musters wieder, da man hier sehr schön die zwei Abstraktionen (Auto und Straße), ihre verschiedenen Implementierungen und ihr Zusammenspiel (jedes Auto benutzt beliebige Straße auf gleiche Art und Weise) sieht.
Gruß Der Unwissende