Book Review: Elemental Design Patterns 129
jkauzlar writes "Believe it or not, it's been 18 years since Design Patterns by Gamma, et al, first began to hit the desks of programmers world-wide. This was a work of undeniable influence and usefulness, but there is criticism however that pattern-abuse has lead to over-architected software. This failure is perhaps due to wide-spread use of patterns as templates instead of understanding their underlying 'grammar' of this language such that it may be applied gracefully to the problem at hand. What's been missing until now is a sufficiently authoritative study of design patterns at this 'grammatical' level of abstraction. Jason McC. Smith, through a surprisingly captivating series of analytic twists and turns, has developed a theory of Elemental Design Patterns that may yet rejuvenate this aging topic." Keep reading for the rest of Joe's review.
Much as developing a large taxonomy of star-types in astronomy lead to and enabled theories of star formation, or a classification of organic life lead to studies of genetics, it makes sense that the large volumes of collected object-oriented design patterns should somehow lead to a generic understanding of them. Smith actually approached this in an attempt to solve a very practical problem: given the variety of ways a particular pattern can be implemented, how can one be recognized programmatically with a degree of certainty?
Elemental Design Patterns | |
author | Jason McC. Smith |
pages | 368 |
publisher | Addison-Wesley Professional |
rating | 9/10 |
reviewer | Joe Kauzlarich |
ISBN | 978-0321711922 |
summary | Software Design |
What's most fascinating about Elemental Design Patterns is the analysis performed in working out a solution to the question of how a pattern may be defined in a way that's language-agnostic and flexible to differing implementations. This was a success: his resulting pattern recognition tool even found unintentional usages of well-known design patterns in a large legacy code base, which could then be refactored from the ugly 'accidental usage' to transform apparent chaos into maintainable order.
The basic idea is that every pattern is composed of elemental patterns. For example, the 'Factory Method' pattern may be decomposed into four EDPs (elemental design patterns): 'Create Object', 'Fulfill Method', 'Conglomeration' and 'Retrieve'. The 'Pattern Instance Notation', introduced in this book, and which serves as an extension to UML, helps visualize the relationships between the four sub-patterns and the larger pattern. No doubt readers will find the notation useful in their own work.
This premise's success or failure hinges on two questions: are the set of patterns really elemental? and can the set of patterns be complete? Oddly, the patterns listed in the book are NOT complete: "this book touches on only one-quarter, at best, of the possible EDPs that exist" (p. 107). The fact that this book (which defines 16 patterns in depth) is only the beginning of a project is not well-communicated. Those who might benefit from a complete listing of EDPs (i.e. analysis tool makers) might be puzzled at how to immediately put this book to use if it's not complete. After all, Smith insists in the Preface that "this book is meant to be used." To me, this implies it should serve as more than a basis for research or design-skills edification.
As for them being elemental, in the sense that all possible 'macro-patterns' may be built from them, Smith backs up this claim with the help of a mathematical formal system called rho-calculus, which is introduced in some depth in the appendix, but avoided in the body of the text for readability's sake. Readers wanting a full mathematical treatment are referred to Smith's Ph.D thesis.
What makes the book worth reading and re-reading is in the methods employed to analytically derive EDPs. As dull as I probably make it sound, Smith gives the entertaining first half of the book an almost 'novelistic', first-person quality in which the reader is engaged to experience Smith's insights first-hand. In a sense, the EDPs are 'unfolded' from simple concepts like the degrees of method or object similarity in a method-call relationship.
Understanding this point is important to understanding EDPs: a method call is not just a method call from a 'micro-patterns' perspective. Calling a very different method on the same object is semantically distinct from calling a very similar method on a very different object. The first is described by the EDP 'Conglomeration' (breaking larger tasks into subtasks); the second, by the EDP 'Redirection' (redirecting a process to another object). Of course, the terms 'similar' and 'different' are fuzzy qualifiers to programmers and there's bound to be some debate on how these terms are applied. Smith, in order to make this distinction, puts faith in the developer's ability to name classes and methods. But anyway, such 'semantic' relationships are the real building-blocks of the higher-level patterns. Once other object-oriented principles are considered, like inheritance, the EDP list grows.
The importance of Elemental Design Patterns from a designer's perspective should now be more clear. I kept stressing the word 'semantic' in the last paragraph because what this book strives to do is provide a *language* for describing object-oriented structure that, first of all, doesn't rely on the OO language itself (C++, Smalltalk, Java, Javascript, etc), and more notably, which takes into account the designer's purpose for employing simple devices like method calls and class extension. As I said earlier, a method call is not just a method call. There may be a dozen or so 'structural' reasons to call a method, and each reason is given it's own 'word' (i.e. EDP) in Smith's language. It stands to reason that a designer with a firmer grasp on his own intentions is a more effective designer.
You can purchase Elemental Design Patterns from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
That was painful (Score:5, Insightful)
That review painful to read. Dunno if it’s the verbosity or what but it felt less technical and more like prose. I think too it got a bit too much into the books contents, almost trying to paraphrase the book. It’s supposed to tell me whether I want to read the book, not provide me the Coles notes version.
As for the topic itself, while I find it interesting someone has done serious analysis on the topic, I think in practice it comes down to three things:
1) Experience
2) Common sense
3) Checking your ego at the door
First one applies to everything. OO design is harder than people think. It takes long term experience and many failed approaches before one develops an intuitive sense of what is going to work at well in code as does on paper.. and what will survive the inevitable scope changes and end of project quick hacks with some elegance in tact.
Second one kinda ties in with the first one. Design complexity should match project scale and expected maintenance. Don’t abstract stuff that is very unlikely will ever need to be changed/will require massive re-write anyway. Abstract the hell out of stuff that would likely change.
Annd third one ties into the second one. A lot of OO insanity comes from people trying to show off how big their brain is by cramming every design pattern they can think of into the software. Hey look, I created an abstract factory that takes a creation behaviour (built from an abstract behaviour) and covered it up in a facade! Just code it the way it makes sense, not what makes the most badass class diagram!
That's not to say design patterns arn't useful. But I view them as problem solvers, not general usage code. You shouldn't instinctively try to use design patterns for everything.
Patterns over hyped? (Score:5, Insightful)
I am a senior developer at a large publicly traded company. We have some pretty high volume systems, and I have yet to really use any other patterns besides MVC in my daily activities. I have also worked at several smaller consultant firms and never used them much before my current place. Maybe it's just because the type of problems I have been working on aren't complicated enough?
Re:Patterns over hyped? (Score:2, Insightful)
I always through most of the patterns in the Design Patterns book could have been better described as 'Workarounds for language(or library) limitations'
Re:Patterns over hyped? (Score:2, Insightful)
Re:Patterns over hyped? (Score:5, Insightful)
Alternatively you have implemented additional design patterns without knowing it.
That's something I've seen a lot - just because someone doesn't know a name for something doesn't mean that they can't use it. In interviews I've asked people to explain the factory pattern (arbitrary example) to me - and had them draw blanks. But a few questions reveals that they're familiar with it, and just never associated it with the name "factory pattern".
Re:What has been missing is critical thinking. (Score:4, Insightful)
I think you nailed it in the first sentence.
People have it in their heads that the crazier the class diagram, the easier the software will be to maintain. Obviously this isn't the case. Sometimes a design pattern can be used to provide useful abstraction or turn a complete hack into an elegant solution (or provide new and exciting hacks.. see: singleton) ,, but often it just adds extra classes that abstract things so core to the program that they will never change without a complete do-over .. or just adds useless layers of indirection that make it impossible for future maintainers to figure out what the hell anything does without using a debugger.
I think applicability comes down to justification. Can you justify the usage of this pattern? If not.. don't use it! Treat them as things to use when there is a reason, not things to just always use.
Re:Design patterns were the worst thing to happen. (Score:5, Insightful)
Design patterns served the purpose of giving names to the things that as you said, most coders already came up with. When I say strategy, or observer, or behavior, or singleton .. everyone knows what the hell I'm talking about.
I know I'm coming across as an arrogant snob but since when did programming stop being a profession and start being a free for all for all liberal arts failures who can type a line of C# and suddenly think they're Turing?
When we did what we do with everything.. made it easier. It's the natural progression. People said "hey, this is hard.. if we did it this way, it'll be less hard". Rinse and repeat. There's still hard stuff out there, but it's not common _because_ the common stuff has been made easy. If you want to be challanged, get a job doing something weird that hasn't benefited years of people doing the same thing and improving the process.
Re:The biggest problem with design patterns... (Score:4, Insightful)
On the other hand, if you spend all your time re-solving things which have already been solved.. you aren’t going anywhere fast either.
Ultimately design patterns already existed. Most of the commonly used ones are intuitive enough that most programmers arrived at them on their own. The main purpose served was creating a common vocabulary.
Re:Patterns over hyped? (Score:5, Insightful)
Patter are simply giving names to the same things we've been doing for many, many years, and they're useful because of that. You can now describe your approach to a solution without showing actual code. Obvious examples most people will recognize are the Observer patter, Publish/Subscribe, and Factory. Many people implement these themselves long before someone gave an 'official' name to the solution. You use the right solution for the problem at hand, patterns just give a name to it ... or at least that's what they're supposed to do. I realize that some people consider it a contest to see if they can 'collect the whole set'.
Re:Design patterns were the worst thing to happen. (Score:4, Insightful)
You can be a complete knuckhead.. and write absolutely terrible code. But if your using java.. it'll still probably work and after a while of hacking out the bugs (with more ugly code) it'll attain a surprising stability.
And with this crap code, people will spend twice the amount of time (or much more time) trying to maintain it or even trying to add a simple enhancement. In addition, the system will be such a piece of crap that it will be short listed for a complete rewrite. A system with well written code does not need a rewrite every 2-3 years... It can last. I have web-based systems that are 10 years now and still do not need a re-write. When a change is requested, it is easy to find the right place to make the modifications and when you go back into a certain block of code, it is easy to understand what the code is doing even if you have not looked at it in over a year. That saves money in the long run, not cheap coders.
We get cheap coders because analysis of the business case shows you save more from the cheapness of the coders than you lose from the crumbiness of the software.
Please tell me where you work so I NEVER apply there.
You get what you pay for, and slop code will always cost more in the long run. In addition, an expensive developer who truly understands what he is doing will code faster and with fewer errors. Depending on how bad of a hack job is done by your cheap coders it may even save money with the initial expense.
Back in 2002, I was outsourced/offshored. I was one of the first to go because I found a new job immediately and left instead of training my replacement. I spoke with my friends/colleagues that were left behind and the first assignment to the offshore company would have taken me 16 hours to complete. They billed a total of 120 hours for the same work. In addition it went all the way into production and failed miserably with a syntax error... They did not even test it!!!
Now the outsourcing company actually told us that money was the only reason why we were offshored. They said that the client rate was $90/hour for us and $60/hour for the offshore help. If you do the math, that meant the project cost was $7200 for the cheap coders, instead of $1440 for the expensive developer. Not to mention, I am sure some MBA is telling the executives that their cost saving plan saved the company $3600 on this change alone and that they deserve bonuses when really, they just lost $5760.
Now how do cheap coders save money?