Vorbereitung zu Praktikum 3

Transkript

1 Vorbereitung zu Praktikum 3 Menü-Toolkit und Command Pattern

2 Fallstudie zu Vererbung und Polymorphie: "Menü-Toolkit" Anwenderfreundliche Programme werden mit Menüs gesteuert In objektorientierten Anwendungen werden Menüs und Menüeinträge durch Objekte repräsentiert. Ein rudimentäres Menü (Objekt vom Typ Menu) besteht mindestens aus einem Titel (Member titel vom Typ string) mindestens einem Menüeintrag (jeder solche Eintrag ist selbst ein Objekt vom Typ MenuItem), einer zugeordneten Aktion ( ), die alle Menüeinträge anzeigt, den Nutzer zur Auswahl auffordert (prompt) die Nutzerauswahl entgegen nimmt (Maus-Click, Short-Cut), * HAUPTMENÜ * c...copy p...paste u...undo r...redo Ihre Wahl? a und die den vom gewählten Eintrag angebotenen Service zur Ausführung bringt.

3 Ein (schlechtes) Klassen Design Menü und Menüeinträge stehen in einer "part-of"-beziehung (Aggregation). Application add(document) vector<device> Document open() close() copy() paste() Menu add(menuitem) remove(menuitem) vector<menuitem> titel prompt shortcut item MenuItem titel prompt shortcut item-> Durch Generalisierung der Klassen Menu und MenuItem erhält man diese Vererbungsstruktur. offer() zeigt den Short-Cut und den Titel auf dem Display Client MenuItem =0 offer() Menu_Base titel, prompt, shortcut Menu add (MenuItem*) remove(menuitem*) vector<menuitem*>

4 Implementierungsansätze class Menu_Base { Client protected: string _shortcut; string _titel; public: Menu_Base(const string& shortcut, const string& titel) : _shortcut(shortcut), _ titel(titel) { } virtual void =0; virtual void offer(); string getshortcut(); // Accessor string gettitel(); // Accessor =0 offer() MenuItemTask Menu_Base Menu add (MenuItem*) remove(menuitem*) class Menu : public Menu_Base { Field<Menu_Base*> _menucomponents; char _itemselector; string _prompt; public: Menu( const string& shortcut, const string& titel, const string& prompt, Cmd *pcommand=null ); virtual ~Menu(void); virtual void ; virtual void add( Menu_Base* mb ); virtual void remove( Menu_Base* mb ); int size() const; int find( const char shortcut ); }; void Menu:: { // Alle Menüeinträge auf dem Display anbieten // Dem User die Möglichkeit zur Auswahl bieten // Die Auswahl entgegennehmen // Den ausgewählten Menüpunkt identifizieren // Für diesen Eintrag aufrufen // Fehlerbehandlung bei ungültiger Auswahl. }

5 Warum ist das ein schlechtes Klassendesign? Ein Menü-Objekt verwaltet (Anmeldung, Abmeldung) seine Menü-Einträge in einem Feld Wird es ausgewählt, so bietet seine Methode die Menüeinträge zur Auswahl an. Jedem Menüeintrag ist eine eigene Klasse gewidmet (z.b. ItemOpenDoc oder ItemCloseDoc) die im Sinne ihrer Aufgabe redefiniert. Prroblem: Klassenstruktur des Menü-Toolbox ist dann weitgehend von der speziellen Anwendung bestimmt, in der es eingesetzt wird, und müsste zudem bei jeder neuen Anforderung seitens der Anwendung geändert werden. Als Toolkit bezeichnet man allgemein eine Sammlung von Bibliotheken, Klassen und Schnittstellen, die das Erstellen von Computerprogrammen vereinfachen sollen. Toolkits müssen nichts von den Anwendungen wissen, die sie benutzen, d.h. es bestehen keine Abhängigkeiten zwischen ihnen. Anwendungen müssen nur die Schnittstelle des Toolkits (hier: Schnittstelle der Basisklasse Menu_Base) kennen, um sie benutzen zu können. Kernfrage: Wie soll ein Menüeintragsobjekt einen Service- Auftrag ausführen, ohne etwas über den Serviceerbringer oder die Service-Ausführung zu wissen?

6 Das Command Pattern Aufgaben Service-Anforderungen an Objekte richten, ohne die Servicedetails und/oder den Empfänger der Anforderung zu kennen Viele Funktionen können von unterschiedlichen Stellen aus aufgerufen werden, z.b. Menüeintrag, Button, Popup-Menü bei Rechtsklick, Tastaturkürzel Soll jedesmal die Funktion dahinter implementiert werden? Befehle sollen rückgängig gemacht werden können (Undo) oder sie sollen erneut ausgeführt werden können (Redo). Wie kann man das speichern, wenn die Operationen eng mit den Objekten, die sie aufrufen, verbunden sind?

7 Lösungskonzept Den Befehl in einem Objekt kapseln! Das Befehlsobjekt kennt den Befehlsempfänger (Receiver) kennt den von diesem auszuführenden Service (Aktion) weiss auch wie die Aktion rückgängig zu machen ist (merkt sich z.b. den alten Zustand) Vorteile Ein und derselbe Befehl kann von mehreren Objekten aus aufgerufen werden. Die Befehlsobjekte können in einer Befehlsgeschichte gespeichert werden. als Parameter wie andere Objekte herumgreicht werden, nachdem Sie erzeugt wurden. Entkopplung von Aufrufer und Empfänger eines Befehls: Der Aufrufer braucht den Befehlsempfänger nicht zu kennen, sondern nur die Befehlsschnittstelle.

8 Entwurfsmuster Command (Command Pattern) Die abstrakte Klasse Command definiert das Interface zur Ausführung eines Befehls ConcreteCommand (z.b. OpenCommand, CopyCommand) implementiert die execute()- Methode der Klasse Command so, dass der Receiver die gewünschte Aktion ausführt. Der Client (meist eine Managerklasse) erzeugt ein ConcreteCommand-Objekt und weist ihm den Receiver zu. Der Invoker (z.b. ein Menüobjekt) befiehlt seinem Befehlsobjekt, den Receiver die bekannte Action ausführen zu lassen. Der Receiver (Textdokument, Anwendung) weiß, wie die entsprechenden Operationen auszuführen sind.

9 Teamwork Sequenzdiagramm der Objekte beim Command Pattern 1. Client (z.b. Managerklasse) erzeugt Command-Objekte und setzt den Receiver. 2. Client übergibt das Command-Objekt an den Aufrufer 3. Aufrufer beauftragt das Command-Objekt mit der Ausführung des Befehls 4. Das Command-Objekt leitet den Auftrag an den Receiver weiter

10 Implementierungsfragen Wie intelligent sollte ein Command sein? Ein Extrem: Ein Command delegiert die Befehlsausführung sofort an den Receiver. Das andere Extrem: Ein Command (z.b. CopyCommand) implementiert alle anfallenden Aufgaben intern Es liegt im Ermessen des Programmierers, ob er einen der Extremfälle oder irgendwo dazwischen programmiert. Support für Undo und Redo Dazu muss ConcreteCommand zusätzlichen Speicher reservieren: für das Receiver-Objekt die der Receivermethode zu übergebenden Parameter für die Orginal-Werte, die bei der Befehlsausführung ggf. geändert werden. Wie vermeidet man Fehlerakkumulation beim Undo-Prozess? indem das command-objekt ausreichend Daten sppeichert, um den Orginalzustand wieder herzustellen. Benutze C++ Templates um nicht für jede Kombination von Receiver und Aktion eine Command-Subklasse deklarieren zu müssen.

11 Anwendung des Command Patterns beim Menu-Toolkit Application add(document) vector<document> Menu add(menuitem) remove(menuitem) item MenuItem Command* cmd cmd Command execute() Document vector<menuitem> open() close() copy() paste() cmd->execute() Man braucht jetzt nur noch einen Datentyp MenuItem zur Repräsentation der Menüeinträge. Beim Erzeugen eines MenuItem-Objekts durch die Application (=Client) wird ihm der Receiver bekannt gemacht. Nachdem das Menü-Objekt die Benutzerauswahl kennt und das zugehörige MenuItem- Objekt identifiziert hat, fordert es dieses auf, bei seinem Receiver die Serviceaktion abzurufen. Die abstrakte Klasse Command definiert für diesen Zweck eine einheitliche Schnittstelle in Form der Methode execute() Von Command abgeleitete Klassen (z.b. CommandOpen, CommandCopy,...) redefinieren diese Methode und delegieren dabei ihrerseits die übernommene Aufgabe an den dafür vorgesehenen Receiver.