Revealing Module Pattern in CoffeeScript

My friend Colin introduced me to CoffeeScript last week through Mindscape’s Web Workbench.  As I started to learn CoffeeScript, the first thing I wanted to do is to hand translate some of my JavaScript files to see how the CoffeeScript compiler would convert them to JavaScript so I would end up with the functionally same code in the end.

I use the Revealing Module Pattern quite a bit. I found an implementation written by Burk Holland and in the comments of Burk’s post Steve Howell and Elijah Manor provided additional implementations.  Although, Burk’s example came close to what I was looking for in simplicity and cleanliness, I felt that there could be some improvements:

  • It defined the module in the global namespace.  I always create my modules in a namespace I define for the my project to further protect against naming collisions.
  • I didn’t like how the module ended with the definition of a variable to contain the  public functions.

I put forward the following:

I use the existential operator to use my project’s namespace if already defined or to create a new one.  Although, the || operator does produce nicer JavaScript output.  I’m sitting on the fence to which way to go.

I create an object as the last expression in the function that will be returned.  This skips the creation of the temporary variable that is never referenced. 

I’m pretty happy with the JavaScript that is produced.  It very closely matches how I implement the Revealing Module pattern in JavaScript, and it upholds the simplicity and cleanliness of CoffeeScript.

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".