It’s interesting to see that the Design Patterns book has been coming under mild fire lately. I say “mild” because what I have seen so far is more of a criticism than an all-out attack.

Over the past year, I have been giving a presentation called “Designing for Testability” in which I offer a few recommendations and observations on what a developer needs to do to make their code more testable.

When I started thinking about this topic, I was surprised to realize that some of the guidelines that one needs to follow in order to make one’s code more testable are directly at odds with some principles that we have taken for granted for such a long time. The principles under attack come from various areas, such as object-oriented programming and, not surprisingly, Design Patterns such as those described in the book. I’ll list two of these ideas below just to give you an idea, but I’ll save a deeper discussion of what I mean for a future post, since I’d like to make a different point in this article.

Here are some of the principles you need to question if you want to make your code more testable:

  • Extreme encapsulation. It’s a good OO principle, but it can make testability challenging.
  • The Singleton pattern. While Singletons themselves are not necessarily harmful, their recommended implementation so far — using static methods and variables — usually leads to code that’s hard to test.

Having said that, I think the characterization that “Design Patterns aren’t”, from a presentation given by M. Dominus in 2002, is wrong on many points, as is the more recent follow-up by Jeff Atwood on the same topic.

In this article, I find that the author is doing two questionable things:

  • Criticizing Design Patterns without offering an alternative.
  • Making a parallel between Alexander’s construction Design Patterns and software ones.

The first point is probable more of a personal one: I highly respect the practice of criticism, but if is not followed by concrete proposals to remedy the problem, I find the attitude very questionable. Like we say, “La critique est facile, l’art est difficile”.

The second point deserves a more lengthy response.

Alexander’s book leaves a lot of room for art and personal creation, which shouldn’t come as a surprise: building is indeed an art, and the final work needs to be both safe and functional and pleasant to the eyes of onlookers, residents and occasional visitors alike.

The part of art in software engineering is, in my opinion, much more restricted. There is only so much beautiful code or harmonious class hierarchies that you can create. Conversely, the foundation of a software architecture must obey a lot of fairly strict rules in order to be solid, maintainable and evolvable.

Criticizing Design Patterns is like saying that the nuts and bolts that keep a bridge together shouldn’t be designed with templates and cookie cutters found in factories, but instead, be more open to the creative thoughts of engineers.

There is a reason why it’s important to establish a clear separation between Alexander’s Design Patterns and the GOF’s Design Patterns: software engineering is nowhere near as advanced as building engineering is. We are still working on these nuts and bolts, and whenever a new software project starts, we still can’t be sure it won’t collapse under its own weight after just a year. To make a parallel: imagine a world where every time a new construction takes place (say, a bridge), the future of that bridge depends on the team of engineers and workers you choose to build it…

Scary thought. It’s a relief to think that while we might still be building ugly buildings and towers, we can be reasonably sure that the engineering principles that underlie these constructions are scientifically sound and empirically proven, and that these building won’t collapse into a pile of twisted metal for no reason.

The reality is that we are still struggling in software to reach this kind of certainty. We haven’t quite invented software nuts and bolts yet, but the GOF’s Design Patterns book is a very good start that no software engineer should ignore. Yes, there is a good amount of cookie cutter recipes in this book, but I see this as a good thing. The more templates we come up with to lay out software foundations, the more software developers will be allowed to focus on aesthetic considerations.

Our software needs to be solid before it can be beautiful.