Your wish is my command! The Command Pattern - A Foreword

Ch. 6 from HFDP - Part 00 of 03

Target Audience: This series is pitched at developers interested in Object Oriented Design Patterns using the Moose framework in Perl. I cover the examples from the Head First Design Patterns book, replicating Java implementation in Moose. You need to obtain a copy of the book, which is not hard to come by.

Long, long ago, (in a Galaxy far, far away,) we developers wrote code for command-line applications. Whatever data the application required from the user, it collected through a questionnaire with the user. Though we took a certain amount of justifiable pride in the usability of our applications, the problems of the command-line format were obvious to all but purists. For one, the Q&A format gives the user only one opportunity to get it right - or abort start all over again. On occasion, the Q&A format results in a long form that is about as tiresome to fill as doing taxes. But all of that, one could live with as along as the application beautifully (and dutifully) delivered results as expected. The hurt came when from the challenge of managing relationships among the components of data. There was no good way to manage that, since a Q&A format confines the human-machine interaction to a linear script.

Imagine two people having a conversation in a linear format, where one can talk at a time and they may only talk in turns. Might work, hmm? Unless it's a United States law-maker fillibustering Congress. Now imagine half-a-dozen people sitting across from each other and trying to have a conversation following the same linear structure - only one may talk at a time and they talk by turn, in a fixed order. Can you see how that limits the range and variety of topics in the discussion? No? I have a punch-card machine that might interest you ..

(Or take a word-processor, for example, that enquires, "Should I insert an image now?" after each and every line you type. Or asks for style elements after each and ever word .. you get the picture.)

As the world moved into an information age and attention spans shrank reducing humans to tittering twittering twits, Graphical User Interfaces became the dominant paradigm of human-machine interaction.

Enter the Command pattern. A GUI is nothing but a collection of elements that receive data and fire actions. The data are pushed into a structure that resembles a tree and is global in application scope. The action wired to a GUI button typically takes the shape of a script - the so-called 'Callback' - that can access (and modify) the tree data-structure. Nifty! But that is how it used to be. Life has become better since then. And that is where the Command pattern really shines.

The folks at HFDP use a remote control as a metaphor for a software application with GUI. This homily doesn't detract (or distract) from the principle, which is that an application with GUI has a structure as follows:

1. A high-level API
representing functionality presented to the end-user; in the book, it is the Remote Control.
2. A low-level API
representing the proletariat - the classes that implement the methods required to execute the work; in the book, this layer comprises the Household Devices - appliances such as ceiling fan, hot tub, stereo, etc;
3. A mid-level API
representing an abstract layer between the low-level API and the high-level API; The classes at this level each present a generic method like execute() or do() that wraps around the methods of the low-level API.

We shall start with the low-level API. It is instructive to follow the implementation here - usage of Moose attributes is amply illustrated. Next, the mid-level API. There is an interesting illustration or Roles lurking here. And finally, the high-level API - I intend to use this as an illustration of the Life-Cycle approach to Software Development.

On to the code then.

All code in this series may be downloaded from:
http://sites.google.com/site/sanjaybhatikar/codeunquote/designpatterns-1