| Pattern Hatching: Design Patterns Applied / John Vlissides | ||||||
| Reviewed by Tal Cohen | Friday, 07 January 2000 | |||||
The book is basically a collection of Vlissides’s columns in C++ Report, and this is arguably the book’s weakest point: if you’re not intimately familiar with the little details of C++, you’ll miss much of the action. This is sad, because the original Design Patterns book was careful to present patterns in a relatively language-independent manner, both in C++ and in Smalltalk. Here, the view is strongly biased towards C++, in ways that sometimes would annoy (or amuse) users of other languages, such as Smalltalk or Java. Consider, for exmaple, Chapter 3: “Themes and Variations”. A large portion of the chapter deals with the de-allocation problem of Singleton objects. Any programmer who uses a garbage-collecting language will be simply amused by the entire hoopla. The only conclusion from the entire discussion, one that the author himself admits (p. 69 and elsewhere), is that the lack of garbage collection greatly increases design complexity, in addition to program complexity. A design that had the potential of being elegant turns out into an ugly monster by the need to manually manage memory deallocation. Not to mention the suggested use of “delete this” (p. 41). The author is “not sure why, but [...] people wince at delete this”. Hint, John: objects sometimes reside on the stack. In which case delete this can have very... interesting consequences. (True, in the context of a Singleton, where allocation is controlled and cannot occur on stack, this specific problem is not present, and yet “delete this” is such an evil construct, with such horrible possible results, that I’d rather avoid it even in such controlled cases.) And sadly, the entire discussion on the use of Singletons ignores what I’ve come to conlude is the pattern’s worst, and most common, misuse: Singletons, in my experience, are a tempting (and in practically all cases wrong) replacement for global variables. A designer that finds a need for a global variable simply replaces it with a Singleton, and pronounces that not only he’s not using globals, but rather he’s using a known pattern, which must mean his design is good. (To clarify, there are of course good uses to the Singleton pattern; the problem is with the pattern’s abuse as a replacement-for-globals.) Chapter 2 is a tour-de-force of using “classical” patterns, those presented in the original Design Patterns book. The examples look a little forced, and life too simple (every problem has a corresponding pattern that fits it like a glove), and yet it is a most educating read. For one, relatively simple problem, the author comes up with an elegant solution that uses no less than six patterns (Proxy, Composite, Template Method, Visitor, Mediator and Singleton) — and suggests an enhancement using a seventh one (Observer). This discussion alone could be worth the effort of reading the book, as it examplifies the correct and practical use of patterns in real life. The end of the chapter presents a very nice kind of diagram, invented by Erich Gamma, which could be very useful indeed. This “pattern:role annotation”, as Gamma calls it, allows people who are sufficiently fluent in the pattern language of design to immediately grasp the role of different objects, even in a large design. Chapters 4 and 5 are aimed mainly for pattern developers, though this is not clear when one begins to read them. It includes an example of the Gang of Four’s elaborate discussions about pattern design, with lots of quotes from e-mail messages, etc. This is interesting only to a certain extent. The discussion, basically, is about whether Multicast should be presented as a pattern in its own right, or as an adaptation of the Observer pattern. Most of the discussion seemed to be dealing with minute neuances, but the conclusion (the presentation of a whole new pattern, “Typed Message”), is a beautiful one. The concluding chapter (5) is titled “Seven Habits of Effective Pattern Writers”. The name says it all. Though some of the advice presented (e.g. number 5, “Presenting Effectively”) are trivial, others (e.g. number 1, “Taking Time to Reflect”) are very educating. (Don’t be mislead by that simple title, “Taking Time to Reflect”. Vlissides provides some real important tips under this seemingly obvious one.) In conclusion, if you do a lot of object-oriented design, and use (or consider using) design patterns, reading this book can be a good use of your time; but unless you spend time on designing patterns, too, you might wish to simply skim the last two chapters.
| ||||||
 |
 |
Writers vs users [by samwyse] [2 replies in thread] [Unfold this thread] |
©1997-2022 by Tal Cohen, all rights reserved. [About]
Along with all the hoopla surrounding patterns these days comes more than a little confusion, consternation, and misinformation. This is partly a reflection of how new the field is to mainstream software developers even though it’s not, strictly speaking, a new field. It’s a fast-moving field too, creating vacuums of facts. And yes, we pattern proponents deserve some of the blame for not educating people as thoroughly as we’d like, though not for lack of trying.