Command and Decorator Patterns for High-Quality GUI Design: 25-Comp-B11 Advanced Software Design, December 2018, Q20

Question 20: Command and Decorator Patterns for High-Quality GUI Design (Part IV)

Question text not reproduced: the examination questions are © Engineers and Geoscientists BC. Open the official past paper (linked at the top of this page) to read the question, then follow the worked solution below.

Command encapsulates a user action (a menu click, a toolbar button press) as an OBJECT with a single execute() method, rather than wiring the widget's event handler directly to the business logic it triggers. This decouples the GUI element that invokes an action from the code that performs it: the SAME SaveCommand object can be attached to a menu item, a toolbar button, and a keyboard shortcut simultaneously, with none of the three widgets needing to know how saving actually works. Because each Command is a first-class object, it can also implement an undo() counterpart, which is how professional GUI applications support a general Undo/Redo stack: every executed Command is pushed onto a history list, and Undo simply pops and calls the corresponding undo(). Without Command, undo logic would have to be hand-written per widget-triggered action, scattered across event handlers instead of centralized as reusable, symmetric execute/undo pairs.

Decorator (Question 15) adds visual or behavioural embellishments to a GUI widget dynamically and compositionally, without subclassing the widget for every combination of embellishments needed. A plain TextView widget can be wrapped in a ScrollableDecorator (adds a scrollbar) and further wrapped in a BorderedDecorator (adds a border) — each decorator implements the same widget interface and forwards to the wrapped widget, adding its own touch before or after. Subclassing would need a separate class for every combination (ScrollableTextView, BorderedTextView, ScrollableBorderedTextView...), growing combinatorially; Decorator keeps it to one class per independent embellishment, composed as needed at runtime.

Quality impact of both. Command keeps action-triggering widgets thin and reusable (the same action wired to several widgets) and makes undo/redo a systematic, centralized feature rather than an ad hoc, per-screen implementation. Decorator keeps the widget class hierarchy from exploding combinatorially as more optional visual features are added, and lets end-user-configurable UI features (turn on a border, add a scrollbar) be assembled at runtime rather than requiring a new compiled class for every combination.

Concept & Theory: Decoupling the Trigger from the Action, and Behaviour from the Class Hierarchy

Topic: Command decouples WHO triggers an action from HOW it executes (and enables undo); Decorator decouples WHAT a widget looks like from its base class.

Key relations: Command → action-as-object, symmetric execute/undo, reusable across triggering widgets. Decorator → wrapper-as-object, stackable, avoids subclass explosion.

Why this works: Both patterns replace a combinatorial or duplicated hand-wired structure (one event handler per widget-per-action; one subclass per feature-combination) with a small set of composable objects.

Common pitfall: Wiring business logic directly into an event handler "since it's simpler for one button" — this is exactly what blocks reusing the same action across a menu item, toolbar button, and shortcut, and blocks adding undo later without a rewrite.

Source: Gamma, Helm, Johnson & Vlissides, Design Patterns, "Command" and "Decorator" (behavioural and structural patterns respectively).

Question 20 of 28: Command and Decorator Patterns for High-Quality GUI Design

Question 20: Command and Decorator Patterns for High-Quality GUI Design (Part IV)