Slashdot Mirror

← Back to Stories (view on slashdot.org)

Book Review: Elemental Design Patterns

Posted by samzenpus on from the read-all-about-it dept.

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. 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 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?

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.

26 of 129 comments (clear)

  1. That was painful by Anonymous Coward · · 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.

    1. Re:That was painful by Gr8Apes · · Score: 2

      You shouldn't have posted anon... these are some good points. I'd go further - most software components should be designed with no more than 4 basic patterns in them - this allows for maintenance folks and others to come along later and understand what's going on without 6 months of due process. Note - these are components, not solutions. Components themselves generally should have very little internal abstraction - this means that a component should be testable and verifiable. If you abstract things within it, this becomes a much more difficult process. Lastly, components should follow functional boundaries as much as possible, again, this eases testing and makes for "complete" units.

      --
      The cesspool just got a check and balance.
    2. Re:That was painful by Eponymous+Hero · · Score: 4, Informative

      i have mod points to give you but you are maxed. there is a word for what you're talking about: anti-patterns. http://en.wikipedia.org/wiki/Anti-pattern

      --
      insensitive clod overlords obligatory xkcd car analogy russian reversals whoosh pedant fanbois ftfy in 3...2...1..PROFIT
    3. Re:That was painful by plover · · Score: 2

      I fall into the category of "write simple methods that are easily proven with automated unit tests." When it comes to patterns, if I see one, they tell me "because you did it this way, it means X to performance, Y to maintainability, and Z to correctness."

      I care a lot more about design principles than about design patterns. Give me simple and clear code first. When it follows a pattern, I'll understand the consequences quicker. If it's close to a pattern, I'll stop and think about the differences. Why did you do this? What does this change solve? Your design doesn't have to follow a published pattern, but it has to have a valid purpose.

      --
      John
    4. Re:That was painful by jkauzlar · · Score: 2

      Reviewer here.. you say 'It's supposed to tell me whether I want to read the book, not provide the Coles notes version.' So, how should I know whether you want to read the book? I'd prefer to tell you what it's about and you're free to decide whether it's something you'd be interested in. I did find it interesting, but I really don't know the scope of the potential audience for such a book.

      As for your critique of design patterns in general, you're spot-on, but nothing new. The same critiques have been made repeatedly for at least 10 years and yet people continue to find a few patterns catalogues useful. I mean, they're basically just common ways of structuring code, so how could that not be useful? Though, as you say, just don't use them as goals to be achieved in order to have cooler-looking class diagrams.

  2. Patterns over hyped? by darjen · · Score: 4, 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?

    1. Re:Patterns over hyped? by Anonymous Coward · · 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'

    2. Re:Patterns over hyped? by thePowerOfGrayskull · · Score: 4, 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".

    3. Re:Patterns over hyped? by Nerdfest · · Score: 4, 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'.

    4. Re:Patterns over hyped? by GreatBunzinni · · Score: 3, Informative

      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?

      I would guess that you do in fact use other patterns, but you actually do so without knowing. That isn't a bad thing, because ultimately what really counts is getting stuff done, and not write some kind of whitepaper announcing to the world that your company's current work is the result of an academically perfect implementation of a wide variety of design patterns.

      Nonetheless, I find design patterns to be very important and extremely helpful, mainly because they can be seen as a set of pre-defined solutions to a set of well-known problems. In other words, they represent building blocks which have been adequately studied and therefore provide important properties that are already known beforehand.

      Knowing these properties is extremely helpful when designing an application, because it lets you minimize the amount of work you will need to do to add some features, or even completely avoid it. By knowing design patterns you are able to come up with solutions to potential problems simply by identifying them and adopting the adequate design patterns to side-step it.

      As an example, let's imagine we were developing some sort of 3D modelling application. We could start by defining that the application would consist of a database component, which stores all the information regarding the model, and a GUI component.

      As you are already familiar with the MVC pattern, we could design the database component with as a model and implement any representation of the 3D model as a different view. But let's go a bit beyond that.

      In a 3D modelling application, we can expect that for each database component we might have multiple views. In addition, we might have an indeterminate number of components which might need to be aware of any information stored in the database. A nice way to pull this off is to design the database component as an observer pattern. By doing this, you are free to extend the 3D modelling any time in the future to add a new component without any trouble at all. In addition, you are also able to completely replace other components by simply taking them off and plug in a replacement.

      A 3D modelling application also needs to provide the user with a way to operate on the 3D model. Yet, more often than not we don't know everything the user wants to do and how he wants to do it. This means that it is a good idea to implement these operators in a way that you are free to add them in the future without being forced to rummage through half the source code tree. A good way to do this is to implement these modelling operators as a visitor pattern. By doing this, you've just defined a generic interface for every operator you might need, and basically you only need to add a single class to implement any extra feature for the 3D modeller. In addition, if you also make sure you also include the inverse operator for every operator then an undo system will pretty much write itself.

      The list goes on and on. You can implement your scene graph by employing a composite pattern, you might implement the components to import models from an assorted list of data formats by writing each component as a strategy pattern, you may implement a series of UI animations and input states around a state pattern, etc

      --
      Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
    5. Re:Patterns over hyped? by JonySuede · · Score: 2

      they both are reification of the Publish-Subscribe pattern. Patterns are use mostly to discus about code in a general way after the fact. It is quite rare to you go on choosing a mediator or a flyweight but looking back at a code base it is easy to find instances of patterns, whatever the language as they are implementation independent. The other use of pattern is to give a distilled experienced to a beginning programmer.

      --
      Jehovah be praised, Oracle was not selected
    6. Re:Patterns over hyped? by Jason+Smith · · Score: 2

      "Unfortunately the Gang of Four book was written partly as a pattern reference, so it's not so easy going as a tutorial for those without either a CS degree or 10+ years programming experience."

      Exactly. In my experience as an educator, I've seen both undergraduate and graduate students struggle with the GoF book when handed it with only the edict "Thou shalt do this." What inevitably happens is that they start copying and pasting the sample implementations as rote mantras, instead of seeing the underlying concepts as mutable pieces that they can work with to create a solution that fits what *they* need.

      That's where the EDPs come in. They give a ground level set of concepts and taxonomy to start composing the more abstract notions in the GoF text. For those new to patterns, they give an introductory way of approaching the literature, and thinking about even the most basic concepts of programming independent of implementation details. For folks who have been using patterns for years, they give (perhaps) a new way of looking at the tools to give them new uses.

      The design patterns literature is full of an immense amount of good information... when it's used well. When it's just copied and pasted, it can easily lead to worse problems.

    7. Re:Patterns over hyped? by Jason+Smith · · Score: 2

      I think you understand design patterns better than most people, to be honest. Copying and pasting a design pattern is the worst way of going about it, IMO. The bit that most people seem to miss, is that if it's not what you need, alter it to suit your purpose.

      That was actually a main reason for writing this book - to try and provide folks with an easier ramp-up to the existing design patterns literature in a way that got across the point that these patterns are both a) composed of smaller pieces that are understandable, and b) made to be custom-tailored.

      It's not the structure of a design pattern that is important, it's the concepts that it embodies. Fulfill those concepts in a way particular to your language, problem, or system, and you're still using that pattern, even if it doesn't look much like the example source provided.

      Of course, it really isn't obvious that that's the case when we haven't had a good underlying taxonomy for those concepts... hence the book.

  3. Why do we bother numerical ratings? by i+kan+reed · · Score: 2

    I can't remember the last book review that wasn't 9/10.

  4. Re:What has been missing is critical thinking. by Anrego · · Score: 3, 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.

  5. Re:Design patterns were the worst thing to happen. by Anrego · · 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.

  6. Re:The biggest problem with design patterns... by Anrego · · Score: 3, 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.

  7. Re:The biggest problem with design patterns... by shmlco · · Score: 2

    "Real pioneering comes from thinking outside of the box, where nobody else has ever tried exploring before. If all you can do is think in terms of the named patterns that other people have already thought of, then I think that's generally only going to hold you back."

    Ummm... this smacks of a distain for formal education, which I typically find in people who lack formal education and training.

    Regardless, patterns are simply tools in the box. They're not the ONLY tools in the box.

    --
    Any sect, cult, or religion will legislate its creed into law if it acquires the political power to do so.
  8. Singleton by Chemisor · · Score: 3, Informative

    Well, singleton is useful, if only because it is the only way to implement the application object right. Doing it as a singleton allows access from outside the object, handles constructor exceptions, and ensures the destructor always gets called. Making the app object into anything else is bad:

    If the app object is a global variable, you can not have exceptions in its constructor; terminate always gets called. Also, you do not get to control initialization order, so if you have any other global objects, they may or may not be initialized before it.

    If the app object is a local variable in main, you can not get a pointer to it from anywhere else (and you commonly need to). The second problem is that the destructor will not be called if someone uses exit() (signal handler) or terminate() (some EH problem), causing many problems of resource leaks if the app object is the root of your object tree, as is often the case.

    If the app object is a static variable in main, that solves the exit() problem, but you still need to set a global pointer to access it.

    Making the app object a singleton, first called from main in a try block, avoids all of the above problems.

  9. What we need... by jholyhead · · Score: 3, Interesting

    ...is a book that assumes you know all of the GoF patterns and gives a list of times when you shouldn't use each one.

    Most people's beef with design patterns is that inexperienced coders sit down and think 'what pattern could I apply to this problem?' or 'how can I change my problem to fit a pattern?' instead of 'what pattern, if any would make this code easier to understand and maintain in the long term?'.

    1. Re:What we need... by Jason+Smith · · Score: 2

      God yes. One of the early examples I saw of this was a Hello World that ran to a couple thousand lines of code, using every conceivable design pattern at once. It was horrendous.

      Engineering is trade-offs, in almost every case. Adding an abstraction to encapsulate a bit of complexity doesn't dodge the fact that under that abstraction you are *adding complexity*. Sometimes the complexity is necessary, and sometimes it is a kludge. Knowing the difference requires understanding what the various underlying concepts you are adding actually mean, how they interact, and what they cost you in terms of implementation or design flexibility given your implementation language, constraints, etc.

      The EDPs are a way of conveying that information about the underpinnings of the current design patterns literature, so that the huge amount of information at our fingertips gets new utility... and hopefully so rising programmers can have a smoother introduction to the literature than we did.

  10. Re:In defense of Patterns by DragonWriter · · Score: 2

    Yes, patterns often are needed due to the inflexibility of your programming language of choice

    Patterns, qua patterns, are only needed due to inflexibility of the programming language. With a sufficiently-flexible programming language, any given "pattern" is instead a piece of library code that needs written once, rather than a template that needs to be reimplemented each time it is used.

    Of course, real programming languages aren't perfectly flexible, so any real programming language is going to have patterns that are useful -- but which patterns is going to vary based on the limitations of the particularl language.

  11. Re:Design patterns were the worst thing to happen. by stretch0611 · · Score: 3, 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?

    --
    Looking for a job?
    Want your resume written professionally?
    DON'T USE TUNAREZ!!!
  12. Re:The biggest problem with design patterns... by Jason+Smith · · Score: 2

    I completely agree. In fact, in the book I show where some languages, such as C#, have started implementing some of these EDPs as basic primitives. I also show how these ideas are implemented in a number of languages (Java, C++, C#, Obj-C, Python, even straight C in a couple of cases) to demonstrate how the language feature set can radically change how you choose to implement a concept.

    Ultimately, that's what design patterns are: concepts. How they get implemented is unique to a language, a problem domain, and a set of constraints and requirements you're working with.

    Change the language expressibility, and you change how you can approach the concepts.

  13. Re:The biggest problem with design patterns... by Jason+Smith · · Score: 2

    *Absolutely*. To me, one of the biggest wins of design patterns is that they let me quickly solve, describe, or *avoid* problems that others have solved, described, and found ways around.

    In fact, the material for the book came from my research in creating a system for the automated detection of design patterns in source code. It was originally intended to find the patterns to help document the system, but it quickly became obvious that the biggest benefit was that it defined the sections of the system that *didn't* need documentation. Other people had already done so. Instead, it let the developers concentrate on the portions of their code that were unique to their implementation. i.e., their innovation.

    I find patterns to be incredibly useful, obviously, but they are often most useful not for what they define, but what they *don't*. The negative space of the system, once it is seen as a system of patterns, is where the real fun starts.

  14. Re:Interesting theory, but is it practical by Jason+Smith · · Score: 2

    Do you by any chance mean Kerievsky's _Refactoring to Patterns_? Have a well-work copy on my desk, and between that and Fowler's _Refactoring_, I see a fairly clear path from the EDPs to patterns-based refactoring.

    It was one of the use cases, after all. :)