So, an hour on Composite Applications Design Patterns. Why not?
Well. The seminal book on the topic, Design Patterns: Elements of Reusable Object-Oriented Software, aka Gang of Four, or GoF for short, casts a long shadow. The argument outlining what patterns are, and how to apply them, is more realization of practice than invention. While many people treat this book as a catalog of insights, or even revelations, it is simply a vocabulary that, once applied, could make it easier for contributors to a group programming effort to understand each other.
Why would you argue with a reference book, other than to raise issues of accuracy or authority? As a contributing author to Sun Microsystem's course on J2EE Design Patterns, I even found it difficult to reprise GoF patterns without parroting them. It was no small effort to refresh each one we covered, and add something to prepare the ground for the J2EE material. Even when I felt I had succeeded, it felt...well, risky. Somewhere between gilding a lily and putting a toque on Michelangelo's David to contemporize him.
But one thing I could easily do without was the tedium of the reference format (Problem, Solution, Benefits, Drawbacks) and dry examples, as I mention in my Amazon review. Who wants to sit through a class modeled after a reference book?
Those were my thoughts some time after watching the JavaOne session on Composite Application Design Patterns, which followed GoF in spirit and in form. A problem was discussed, a solution presented, and the benefits and drawbacks laid out. I'm eager to get the slide presentation as soon as possible, because I sure couldn't stay alert for a run-down of however many patterns spanning however many topic areas of composite design. I hate to admit it, but before long I was hoping for the kind of thing the errant business-type in my classes hopes for: cartoons in the margins, an animated slide, anything that amuses, or just moves. Please, help me stay awake!
Presenting design patterns to an audience requires an approach that engages at least as much as it informs. I realize there are potential pitfalls. It's difficult, for one, to develop a compelling example or two for a practice that is, at its core, a deliberate generalization of many examples. There is also may be, at least in my mind, some resistance to an altered form of presentation that goes against what the Fathers GoF hath wrought.
But here's the thing. All a design pattern really is is a refactoring that demonstrates some deeper property, such as inherent substitutability or, less fundamentally, a useful interface/abstraction, or even cross-platform suitability. It ought to be easy to show how a usable but unruly bit of code would profit from a refactoring into a well-known pattern. All the better if we could demonstrate some "necessary" code change, to see what the difference in applying it might be between ad hoc and patterned code.
Too often I see this kind of work left to the imagination of the reader, for at least two reasons. One, because GoF doesn't concern itself much with demonstrations, either; and two, because you can only do so many complete examples before time runs out. But what would you rather have in an hour's presentation: as many patterns as you can appreciate and apply with confidence, or as many patterns as can be recited according to a received format?