Command Entwurfsmuster

[Bashar]

Das ist einfach ein Platzhalter für die Klasse, die den Befehl irgendwann ausführt. Eine Rolle in der Kollaboration.

[n0nam333]

Liege ich da richtig mit meiner Aussage: "Ist diese Klasse nur da, um Befehle und Empfänger zwischen zu speichern, für eventuelle Redo-Aufgaben." Oder hat sie eine anderen Zweck, weil irgendeinen Aufgabe muss sie ja haben.
Danke im voraus.

[Bashar]

Um das mal einzuordnen: Ist das ein spezielles Problem mit Command, oder ist das erste Entwurfsmuster, mit dem du dich beschäftigst?

[C++ Forumbot]

Dieser Thread wurde von Moderator/in Gregor aus dem Forum Java in das Forum Rund um die Programmierung verschoben.

Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

Dieses Posting wurde automatisch erzeugt.

[n0nam333]

Also ich beschäftige mich das erste mal mit Entwurfsmuster, aber ich würde jetzt schon sagen, dass das eher ein Problem mit dem Commandmuster ist.

[Shade Of Mine]

n0nam333 schrieb:

Also ich beschäftige mich das erste mal mit Entwurfsmuster, aber ich würde jetzt schon sagen, dass das eher ein Problem mit dem Commandmuster ist.

Nope. Ist ein Problem das du generell mit Entwurfsmustern hast.

Nehmen wir ein Beispiel fuer das Command Pattern um die Abstraktion etwas zu reduzieren. Nehmen wir an du hast einen Texteditor und willst dort ein Undo implementieren.

Du hast folgende Klassen:
Document: das ist deine zentrale Klasse die alle Aktionen am Dokument wie Text eingeben, Text loeschen, Text auswaehlen, ... implementiert.
Window: diese Klasse implementiert alle User Aktionen. Also wenn der User eine Taste drueckt, wird diese uebersetzt und die korrekte Document Methode aufgerufen. zB eben wenn ich a druecke, dann wird document.texteingeben("a") aufgerufen.

Nun wollen wir Command implementieren weil wir ja Undo koennen wollen. Wir erstellen also viele Command Objekte fuer die ganzen Aktionen wie text eingeben, text loeschen, etc.

Nun erstellt Window jedesmal wenn es Document eine Aktion aufruft ein Command Objekt und reiht es in die Undo queue ein. Wenn Window ein Undo macht wird das letzte Objekt aus der Undo queue genommen und ausgefuehrt.

Wir haben nun also folgende Aufteilung:
Document: Receiver
Window: Client, Invoker

Aber, wir koennten die Undo Queue auch nach Document schieben und haetten dann dort den Invoker. Oder wir erstellen einen UndoManager...

Pattern beschreiben eine generelle Struktur und keine konkreten Klassen. Es waere auch denkbar dass Receiver, Invoker und Client die selbe Klasse sind. Pattern sind nur eine Beschreibung einer Generalisierung einer Loesung eines Problems. Sie sind nicht die Loesung selber.

[n0nam333]

danke

[Shade Of Mine]

n0nam333 schrieb:

Könnte mir noch jemand erklären wieso man zwischen Aufrufer und Befehl eine Aggregation hat?

Du hast kein Wort verstanden von dem was ich gesagt habe, oder?

Ein Pattern ist nur eine simple Beschreibung für eine mögliche Lösung eines Problems. Es ist NICHT die Lösung selber.

In welcher wirklichen Beziehung Invoker und Command stehen ist irrelevant für die allgemeine Beschreibung. In der konkreten Lösung gibt es diese und jede Gründe für diese oder jene Beziehung. Aber es ist nicht fix. Es könnte zB ein CommandManager die ganze Arbeit übernehmen (der kommt im Pattern zB garnicht vor).

[Bashar]

In der deutschen Wikipedia ist in dem (allgemeinen) Diagramm eine Komposition zwischen Aufrufer und Kommando. In der englischen ist es eine Aggregation. IMO beides Blödsinn -- auch wenn es vielleicht oft so gemacht wird, gehört es nicht zur allgemeinen Beschreibung des Patterns. Das GoF-Buch hab ich leider gerade nicht griffbereit.

[Michael E.]

GoF hat ne Aggregation im Diagramm.

[Shade Of Mine]

UML ist ungeeignet soetwas zu beschreiben, das ist das Problem.

Es gibt nämlich eine Beziehung zwischen Aufrufer und Command. Logisch, der Aufrufer macht ja irgendwas mit dem Command. Nur wie die Beziehung aussieht und ob sie direkt ist (Aufrufer könnte CommandManager ja nur anschaffen) ist eben Situationsbedingt.

[Bashar]

Das kann man in UML als Abhängigkeit modellieren. Aufrufer muss Kommando kennen, aber das wars auch schon ... wie er an die Instanz kommt, ist wurscht.

[Shade Of Mine]

Bashar schrieb:

Das kann man in UML als Abhängigkeit modellieren. Aufrufer muss Kommando kennen, aber das wars auch schon ... wie er an die Instanz kommt, ist wurscht.

Mhm, wäre möglich. Komisch dass das nirgendwo verwendet wird... Fühlt sich etwas komisch an, da Command nicht vom Invoker abhängig ist und umgekehrt. Aber wäre dennoch OK denke ich.

Ich habe mir engewöhnt alles ausser Vererbung in UML nur als abstrakte Verbindung zu lesen. Manchmal lese ich auch noch eine Aggregation als solche, bin da aber immer vorsichtig.

Gerade bei Pattern sieht man teilweise die haarsträubensden Sachen. Da ists viel einfacher eine Linie als "abstrakte Verbindung" zu lesen.

[Bashar]

Shade Of Mine schrieb:

Fühlt sich etwas komisch an, da Command nicht vom Invoker abhängig ist und umgekehrt.

Wieso auch umgekehrt nicht? Der Aufrufer muss das Kommando kennen, sonst kann er es nicht ansprechen. Bei Änderungen am Kommando muss der Aufrufer ggf. angepasst oder neu compiliert werden. Das ist für mich das, was abhängig bedeutet.