Designpattern gesucht
-
Hallo Forum,
ich habe hier ein kleines Designproblem, und keines der mir bekannten Muster scheint so richtig darauf zu passen. Ich habe Objekte, die in einer Baumstruktur vorliegen, die beliebig breit werden kann. Was ich nun möchte ist, dass auf diesen Daten gewisse Kommandos ausgeführt werden können. Dazu wird (beispielsweise in der GUI) per string-Identifier festgelegt, welche Objekt addressiert werden soll, und welche Operation auf diesem Objekt ausgeführt werden soll. Das Kommando wird dann bis zum Zielobjekt weitergereicht, und dieses Zielobjekt wertet dann das Kommando aus. Gegebenenfalls werden noch Ergebnisse in das Kommando geschrieben und es wird wieder zurückgegeben.
Meine Frage ist jetzt, ob es ein Designpattern gibt, dass so etwas umsetzt. Command- und Visitorpattern passen nicht direkt, da die Ausführung der Aktionen dort in den Commands bzw. Visitorn passiert. Ich möchte aber dass Auswertung und Ausführung in den addressierten Zielobjekten geschehen, und die Übergebenen Kommandos mehr als Datenkapseln dienen.
Vorschläge, wie man das ganze vom Design her besser aufziehen kann, sind natürlich auch willkommen.. ich bin in dem Thema noch ein ziemlicher Grünschnabel
Es grüßt
vx
-
Du kannst ja auch einfach nur "obj->FunktionDieKommandoImplementiert();" in das Visitor-/Command-Objekt reinschreiben. Dann passiert effektiv auch alles im Objekt, und nicht im Visitor/Command.
-
Hm, das wäre durchaus eine Idee. Das Kommando könnte dann den Datensatz der für seine Ausführung benötigt wird per Referenz an obj->FuehreKommandoXXXaus(&datum1, &datum2...) übergeben. Noch eine Frage dazu: Wäre es legitim diese FuehreKommandoXXXaus Methoden private zu deklarieren, und dann jede jeweilige Command-Unterklasse als Friend zu ihrer jeweiligen FuehreKommandoAus()-Methode zu deklarieren?
Das sind jetzt vllt. ein paar blöde Fragen, aber ich will vermeiden, dass mir das ganze Design in zwei Wochen wieder um die Ohren fliegt, weil es zu unflexibel ist.
Gruß vom
vx
-
Eine andere Möglichkeit wäre eine Chain of Responsibility. Der Parent könnte es dann an seine Kindknoten delegieren, wenn er erkennt das eines davon verantwortlich ist.
-
vx schrieb:
Wäre es legitim diese FuehreKommandoXXXaus Methoden private zu deklarieren, und dann jede jeweilige Command-Unterklasse als Friend zu ihrer jeweiligen FuehreKommandoAus()-Methode zu deklarieren?
Falls du verhindern willst, dass man eine bestimmte Funktion aufrufen kann ohne ein "Command" zu verwenden, dann ist das natürlich legitim.
Die Fragt ist nur ob du das wirklich verhindern willst. Bzw. sollst. Die Funktionen hätten dann ja im Prinzip dasselbe Interface wie die Commands auch.
Andrerseits: wenn ich mir aussuchen kann, ob ich in einem Projekt am Anfang entweder viel zu viel public gemacht habe, oder viel zu viel private, dann auf jeden Fall lieber viel zu viel private.
Wenn etwas private ist, was doch hätte public sein sollen, dann merkt man es eigentlich recht schnell. Spätestens beim Compilieren :). Umgebaut ist sowas meist auch recht flott.
Umgekehrt ist es viel schwieriger, denn wenn ein Haufen fragwürdige Funktionen erstmal für ein paar Wochen oder Monate public waren, dann greifen sicher etliche Programmteile munter darauf zu. Einen so entstandenen "Sauhaufen" wieder aufzuräumen dauert jetzt zwar nicht ewig, aber u.U. doch lange, und vor allem ist es eine ziemlich lästige Arbeit.Sogesehen: ja, klar, mach private + friend. Wieso nicht
-
Danke für eure Vorschläge. Letztlich hab ich beides kombiniert: Die commands werden runtergereicht und rufen dann beim Zielobjekt ihre obj->fuehreXXXaus Methode auf. Ergebnisse werden dann ins command-Objekt geschrieben, welches dann wieder beim aufrufer landet, der die Resultate der Operation weiterverwenden kann.
Es ist doch immer ein bisschen beruhigend, wenn man bei solchen Designentscheidungen ein paar andere Meinungen hört. Also noch mal danke, ihr habt mir sehr geholfen.
Gruß vom
vx
