I recently taught design pattern to 20 of my co-workers in a kind of training session, here are some thoughts I had while preparing this presentation…
In OO you usually end up with many classes, especially when you correctly use design patterns; each class is also generally very simple and rather short. Thus classes are now in OO the equivalent of the “if-then-else-for” instructions in structured programming: low-level language elements.
Unfortunatly, UML is essentially about class-level static description (class diagram), dynamic objects interactions (sequence, object diagram). Even more OO-independent part of UML such as state diagram is still at the class level, as typical implementation using the State pattern (GoF) implies using a class for each state.
What is the higher level above the class-level ? In my opinion, it is the (design) pattern level, for at least three reasons:
– granularity: a design pattern usually deals with more than one class, so it is a natural way to talk about several classes as only one entity;
– patterns language: patterns may be solutions to solve recurrent problems, sure, but they first of all define a common language to talk about the entire solutions in a standard, shared way;
– patterns intent: patterns are always motivated by an explicit intent; this intent is the real high-level need of the developer, whereas the solution that uses classes, methods overriding, methods delegation, methods callbacks… is nothing but the best known way to meet the intent using OO language.
UML support for patterns is quite minimal (dash lined and named bubbles with links to every participant in the pattern), and adds nearly no value compared to simple UML comments. If you know the patterns, and you do if you’re reading this to this line, I’d better tell you “this package contains adapters from the third party financial instruments tree to our custom financial instruments tree” than show you a diagram with 35 classes in a package and 35 classes in another package, 35 interfaces and 35 bubbles showing the pattern Adapter is applied 35 times respectively for each class, class and interface…
In the business design (some say analysis), the same is true. It’s shorter and more accurate to say the model follows the Contract pattern (Fowler), than to show the UML diagram. But on the other side, there is no formal language, visual or textual, other than plain English to describe patterns at their full level. At this level, packages would would be first-class entities, not just boxes that contains classes. Code generation could also go one step further, since if the machine knows about our intent, it could also provide the solution to our intent, maybe by implementing the correct pattern automatically, using the best implementation tradeoff automatically, but now I’m dreaming…
Initially published on Jroller on Tuesday March 15, 2005