LOGIN | REGISTER NOW | SUBSCRIBE
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 7/1/2009 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
Is the mystery Borland suitor Serena?
Borland software is considering an offer from another company after a preliminary deal with MicroFocus. Is Serena the new company?
06/30/2009 01:55 PM EST

Windows 7 - An eBayer's dream product?
Windows 7 pre-orders can make people money on eBay.
06/29/2009 03:48 PM EST

Know thine cloud provider
Cloud computing require companies to understand compliance and regulation. Third parties will play a big role in regulated industries.
06/29/2009 02:58 PM EST

 

Microsoft Worldwide Partner Conf.
7/13/2009 to 7/16/2009
New Orleans
Microsoft

OSCON (Open Source Convention)
7/20/2009 to 7/24/2009
San Jose
O'Reilly Media

XBRL Technology Workshop & Summit
7/28/2009 to 7/30/2009
Santa Clara
XBRL US

ACM SIGGRAPH
8/3/2009 to 8/7/2009
New Orleans
ACM SIGGRAPH

OpenSource World (formerly LinuxWorld)
8/12/2009 to 8/13/2009
San Francisco
IDG World Expo


 
print Printable version 
Most Read Latest News Blog Resources
Kapow automates website data retrieval
Kapow Technology's Web Data Server 7.0 can be used to create modules that navigate through...

COBOL’s future lies in the clouds
After 50 years of use in businesses, COBOL is still lingering around mainframes. But the s...

Oracle's Fusion 11g lays groundwork for ERP platform
Fusion's components are standards-based and integrated, but some abilities are lost if non...

Digg!  Digg
Reddit  Reddit
Slashdot  Slashdot
Share on facebook  Facebook
Share on Twitter  Twitter

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
 

Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading