Got a link to a post via Raganwald's feed the other day (he doesn't post anymore, but he does still throw out links to great posts via his feed), which in turn reference another post titled "Design Patterns are From Hell!"
Both of the posts make plenty of good points, and I don't find myself particularly at odds with anything specific that's been said. Nevertheless, I'm a little worried about some of the ire that's been directed at Design Patterns in general lately. There's been a great deal of anti-patterns ranting these days, and it has me a little worried that the entire point of Design Patterns (as I see them at least) has been completely lost on the developer community. I think a lot of the backlash is equally as bad as the rah-rah attitude that got us into a mess with Design Patterns to begin with.
I'm not a huge advocate for Design Patterns, but I don't hold them in such low regard as most developers now seem want to do. When I first read the Design Patterns book, I understood the premise behind the Gang of Four's writing to be them saying something along the lines of this:
"Hey there! We've been developing software for so many years now that we've noticed a few things that consistently pop up in the structure of our code -- here's the patterns we've found so far. Check 'em out. You might recognize some in your code, too, but if you don't it's really no big deal. We just thought we'd jot them down and see if anyone else has seen similar patterns in their own code."Like building architecture and that other patterns book that many people reference, the GoF guys looked at a bunch of recurring patterns in their software architecture and decided to catalog them. They thought it might be useful to point them out and perhaps find ways that code might be similar across different projects, and maybe use this knowledge in some way to help push software development forward.
Unfortunately, our industry -- with it's silver bullet mentality -- looked at Design Patterns the way we first looked at things like Object-Oriented programming and Agile Software Development: As the Ultimate Solution To All Problems.
Basically a lot of people read the book and saw this:
"Hey There! We've been doing software development for many years now and have noticed some patterns popping up in the architectures of our big, successful projects. We think that if you use these patterns in your projects that you'll succeed as well! Even better, there won't be any need to actually think about your software's architecture! Just plug in that Visitor with a Singleton and a Strategy Pattern and you'll be well on your way to project nirvana!"Which resulted in the kind of thinking that got us projects being considered a total failure if they didn't use all of the GoF patterns explicitly, or that a project could not be successful without these patterns in it.
Design Patterns are not evil, but our use (and abuse) of them certainly has been.
The purpose of Design Patterns was never to be the answer to any specific problem, but simply as a method for recognizing similarities across projects in the hope of perhaps finding some points of commonality that could be exploited in some way, making all developers lives easier. Unfortunately, the industry never saw them that way: Instead of looking for ways that our code was already similar, we tried to shoehorn our code into the patterns so that it would be similar, regardless of whether it really made sense to do so.
And now that software developers have turned their projects (and potentially the industry) into a mess by trying to adapt code to fit the patterns, the patterns have gotten the blame for the results. Design Patterns were merely meant as a means to an end -- to try to come up with ways to make software development easier by examining commonality -- not an end unto themselves. It's not the patterns that should get the blame, but the developers that misunderstood and/or misused them.
The only reason Design Patterns have gone to hell is because we drove them there ourselves.
Posts
3 comments:
We keep taking these good ideas and then drive them to the extreme where they become negative. It's not just design patterns, it's pretty much any coding philosophy. Somehow we've got to learn to use these things within their sweet spots, and not become so rigid that it starts to cause damage.
Paul.
I was actually in the middle of refactoring some code that used the Singleton pattern along with a Parameter Object to pass context state. In effect creating a global data structure. When I read the blog post.
[OffTopic-provides a little more information for rest of the comment]
The consequence, when the code is loaded into the browser via jvm (applet), in multiple simultaneous applets (ohh yeah we have them) results in shared state between applets. The shared state at any given time is valid for only one of the applets.
The use of Singleton and Parameter Object, was clearly wrong, I would go to the extent of classifying their use as irrational, in this "specific case"
The use of parameter object is not incorrect in and of itself and was probably within reason, but the partial use of parameter object (design pattern), not passing it in using method parameters, and shoe horn-ing it into arbitrary sections of code using the singleton pattern was a bad choice.
Developers who have read the GOF book and the gazillion other pages/books on design pattern often use these patterns as a simplification (in a negative sense) mechanism. The patterns were meant to be studied as architectural choices to better structure code. Increasing in the hands of mediocre developers they serve as short cuts. Invariably the short cuts are found out to be what they really are, poor design and code organization choices.
It is not so much the industry or silver bullet mentality that is to blame for the bad rap that design pattern receive recently. I would go as far as to hazard a guess and claim that it is those who complain the loudest who would be perfectly fine with the use of Singleton and Paramter Object as described above.
Nice summary, it's good to read an even-handed assessment.
Post a Comment