Book Review: Elemental Design Patterns

Elemental Design Patterns by Jason McC. Smith adds to the design patterns literature in a significant way; rather than building up more and more patterns that are more and more domain-specific, he breaks down even what are considered elemental design patterns into semantic units that are inherent in object-oriented languages. He’s given the design patterns community a set of building blocks, and an analytic framework for thinking about patterns in, really, any language.

The great thing that comes from identifying the building blocks is composability; the patterns we already know can be composed of these lower-level units. From this we gain new tools in comparing and analyzing them.

The author also introduces a new type of diagram called PINbox diagrams, which elegantly allow you to capture details of roles played in a computation. The best thing about them though is that they can be nested, so they enable looking at a design with different degrees of details. It will be interesting to see if this diagramming technique catches on.

Now, all the goodness aside, I’m not sure that the content or ideas have a great deal of day-to-day, practical use. I don’t think that’s what he was going for though, so that isn’t a criticism. Just a warning; this patterns book is not like other patterns books.

But I highly recommend it if you enjoy design patterns and/or OO languages!


About jeffkotula

Software engineer, musician, and so on...
This entry was posted in Coding, Reviews, Software and tagged . Bookmark the permalink.

2 Responses to Book Review: Elemental Design Patterns

  1. Sounds interesting. I read about Clojure’s implementation of Software Transactional Memory, and he made the really interesting point that with his API, you could compose operations, without deadlocks. That with pretty much any other API, you were doomed to locking far larger swaths of resources for longer than you needed to, or else your performance in the ideal case would suffer.

    Which I thought was really interesting. But then you start reading about how STM works, which is that it tries to execute an operation, and if it collides with some other operation, it keeps retrying. Which might be fine in practice, but it scares the crap out of me.

    And then I read about how hard it is to decide which state is in the STM space, and which state is not.

    And then I read about trying to have distributed software transactional memory, so that multiple computers can play.

    And then I started reading more and more about Haskell, and then I wanted to never read anything about programming on the internet, ever again.

    What I’m getting as is that I’d be interested to see if these building blocks can be applied, even in the strange world of STM, and in the stranger world of Monads, and in the bizarro-world of people worrying about ACID, and how different memory layouts affect cache lines in multi-core computers…

    This stuff is hard, and solving problems in all of these spaces seems to depend on intuition and hard-won experience. I wonder if that will change?

    P.S. — Haskell, what a scam.

    • jeffkotula says:

      IMO, the multi-threading thing is a design problem, not a language problem. Multi-threading is easy if it’s designed right. The concern with optimal performance in an ideal case is foolish I think; if the benefits of parallelizing require ideal performance then you need to rethink parallelizing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s