Windows Workflow and the Command Processor Pattern

I have been doing some Windows Workflow (WF) consulting with a customer lately and I was talking to a developer who had just been thrown onto the project and was struggling with WF, not feeling that he had a solid grasp of the paradigm. No one was more surprised than me when I was able to help him so easily by simply pointing out that WF is an instance of the “Command Processor Pattern”. Because it seemed to help him so much I thought it might be worth sharing here.

Before I get to this however, I just want to state for the record how important I believe the Gang of Four (GoF) Design Patterns book is. I always assume, sometimes incorrectly, that every developer has intimate knowledge of the GoF Design Patterns book. I believe reading it is a right-of-passage for every developer, and I would always steer people towards the original book, as opposed to “knock-offs” that try to “translate it” to another programming language. If you haven’t read it, stop everything and read it!

The Command Pattern

In case you can’t recall it, the authors state the following as the intent of the “Command Pattern”:

Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations

However, I think the essence of it is well captured in the structure diagram:

The Command Processor Pattern

After the GoF authors, the POSA1 authors expanded on the Command Pattern by writing up what they called the Command Processor Pattern, a pattern that built on the Command Pattern to show how easy it is to use it to do things like undo/redo functionality etc. Again, for the sake of brevity, I will only show a single UML class diagram that I think conveys the essence of the pattern:

Compounding Command

Later, two of the GoF authors wrote a paper called “Compounding Commandin which they showed how some of the other GoF patterns can be combined with Command in interesting and powerful ways, which I’ll summarize here by once again showing a single UML diagram that I think captures it quite well:

Finally, WF as an Instance of the Command Processor Pattern

Now, mapping these ideas to WF is, I think, as easy as first of all making the following connection:

Activity à Command

WorkflowRuntime à CommandProcessor

Armed with these mappings, then showing the structural relationship of some of the key classes in WF shows very clearly how it can be conceptualized as the “Command Processor Pattern”:

The Value of Patterns

As a final comment: the GoF authors state explicitly that they weren’t doing anything new but rather placing well thought out names to reusable design nuggets that people had been using for years already. The real value in that was evident in the interaction I had this week with that developer: once he thought of WF in the context of the Command Pattern he immediately understood what I was talking about because the pattern name was part of our "shared developer lexicon".