Clipcode-GoF-DSL and the One-To-One Mapping Anti-Pattern
Last week Eamon O’Tuathail of Clipcode released a Domain Specific Language (DSL) for some of the Gang of Four design patterns using theMicrosoft DSL Tools for Visual Studio 2005.
It is indeed a very remarkable proof of concept and although the implementation is still pretty rough, it represents a valuable model for discussion and learning.
Eamon is very active (particularly) within the Irish community and he is a regular speaker at the Irish .Net Developer Alliance (INDA) events where I often see him.
I briefly talked to him last night as we both were present at the excellent Roy Osherove’s talk on agile development and unit testing best practices.
Eamon told me that he only spent a couple of days developing it; this is something I consider rather impressive given the premature stage of the supporting tools currently available (I bet that his superb documentation took him more time to develop 
).
The DSL designer currently allows setup and code generation for five patterns:
- Abstract Factory
- Builder
- Factory Method
- Prototype
- Singleton
Overall, I liked the organization of the code templates in the debug solution, as they are neatly located in a common folder and are referenced only through the ClipcodeEngineTransform.ReportTemplate file which acts as a *template controller *for all the instantiated designers.
Besides some understandable limitations of both the language and the underlying platform (i.e. the DSL Tools) that will be undoubtedly addressed in future releases, my main interest (and point of concern) lies in the level of abstraction of the model.
Using the language to generate code that realizes a pattern is pretty straightforward as the designer diligently constrains allowable classes and connections.
However, my worry is that, in order to realize a pattern, you need to select every single participant (class/object) from the toolbox and manually connect it to the permitted collaborator(s). As a consequence, you end up creating a diagram that matches quite closely the classic UML representation of each pattern. But do we really need to visualize the structure of a pattern?
As my exploration of the Domain-Specific Modeling (DSM) world progresses, I’m more and more obsessed by the idea that if we want to create the biggest ROI, it is essential to push our models towards a level of abstraction that is significantly higher than the level at which code statements and classes are written.
In other words, a one-to-one mapping between a class created in a diagram and a class generated in code does not generally save enough time and I would dare to consider it an anti-pattern.
A symptom is that the toolbox is generally filled with lots of different elements even if the main concepts (in this case the GoF patterns) are more coarse grained.
So here is a challenge that anyone interested can take. In order to realize an abstract factory, I should need to drag only one class on the designer (e.g. AbstractClassRealization) and setup its participants (AbstractFactory, ConcreteFactory, AbstractProduct, ConcreteProduct) using compartments only. Is it possible? I guess so. I will try soon anyways.
By the way, if you think about it, a GoF pattern is still at a pretty low level of abstraction. In fact, it is the very essence of an OO pattern to address recurring cross-domain concerns. So a “real” DSL may still be built on top of it and possibly provide an even higher return of investment for your organization.
