Patterns as an Anti-Pattern?

By Andrew Binstock

January 15, 2008 —

For reasons that elude me, the arrival of the book “Design Patterns” in 1995 created enormous interest in the programming industry. The book, now known affectionately as the Gang of Four (or GoF) book due to its having four authors, posited a notion that did not seem radical, but which impressed a lot of people—namely, that there were recurring types of programming problems that could be addressed using a systematic sequence of steps.

That sequence of remedial activities was spelled out by the GoF, and these recipes—or patterns—became the object of considerable study. Exponents, such as former SD Times columnist Allen Holub, went on to say that all 23 GoF patterns should be learned, memorized and used by developers. The goal was that at various points in programs you could refer to the pattern and later developers would know from the name what the code did and how. So, for example, if you described a class as a Fa?ade, everyone would know that class was a front-end to some other subsystem.

I like this vision. In pure programming terms, the closest equivalent is collections. When I say that something is implemented as a hash table, you nod knowingly and you don’t need to check out the details of how data items are stored. Unfortunately, the patterns presented by the GoF never obtained the universal implementation that was required for this vision to succeed. Moreover, it turns out the patterns had numerous aspects that are questionable or not terribly helpful. Yet the static perception of their enduring value continues on.

First, let’s clarify that what we are talking about are not really design patterns. They are better described as implementation patterns. They are code-level solutions that help you implement a specific action. They are not the domain of architects and designers, but rather recipes for coders who implement designs. GoF patterns are much closer to the concept of refactoring and coding shortcuts than they are to techniques an architect would use in designing a project.

One problem is that some patterns are so obvious as to make you wonder why they would be singled out as an item of interest; for example, the Fa?ade pattern. This pattern basically suggests that when you have to deal with a subsystem that has a complex programming interface, you write a code layer that simplifies your interaction with that system. You then make calls to your interface, which translates the calls into the complex calls to the subsystem. That is, it’s syntactic sugar. As you can imagine, there is no specific recipe for doing this—since the variations are almost infinite, so it’s hard to see how it’s a pattern at all, as there is no specific prescription for how to do this. The one benefit I detect here is one of nomenclature. I can say to someone I will write a Fa?ade for this subsystem, and they know what I mean.

Another problem is that some GoF patterns that were fairly original have proven to be poor recommendations in practice; for example, the Singleton. The Singleton is a way to jimmy language syntax so that it’s impossible to create more than one instance of a specific class. Over the years, however, it has become increasingly clear that Singletons have very serious drawbacks that often outweigh the benefit of being assured there’s only one instance. Singletons fly in the face of object orientation and force intricate dependencies, which become an enormous obstacle in testing, especially unit testing. And since developers generally prefer the benefits of good unit testing to the syntactical assuredness of a single instance, many are opting to remove Singletons and replace them with normal objects. These developers simply make sure that the object is created just once in the production code.

Other patterns are complex enough that they are the subjects of partial implementations. These include the Factory and Abstract Factory patterns, which can require features that are not needed.

Finally, there is the Interpreter pattern, which says that if you need to embed a small language in your software, follow basic rules to build an interpreter. The trouble is that as the pattern lies, the interpreter model that is proposed could only be used for a trivial language. As the GoF point out, for anything more, you need to use compiler building tools. So, why the pattern?

I should note that many of the remaining patterns are useful and frequently used. However, the prevailing view that the GoF is the defining treatment of patterns seriously undercuts the value of patterns in general. Patterns should evolve over time. There should be new ones added, others dropped, and in all cases thorough testing done before wide promulgation so that what the patterns recommend is truly useful. When that happens, I believe, we will be able to use, depend on, and communicate through patterns in ways that are truly useful.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.

Share this link: http://www.sdtimes.com/link/31612

Information Integration Patterns I’ve been thinking about the patterns of information integration that we see these days, as related to SOA, in products...

Patterns Designed to Deliver the Message IBM has designed six new messaging patterns that may eventually make their way into its software development platform....

Reading About Design Patterns Good software must be designed before it’s built. Code that’s written without the benefit of design takes two to three...

Add comment

Name*
Email*
Country

Comment
Preview

News on Monday
more>>
SharePoint Tech Report
more>>

Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?

Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST