Geeks With Blogs
Amusingly MOSS ...It's funny how difficult some stuff is when it really shouldn't be
I think that the Gang of Four should consider my design pattern recommendations for inclusion in their codified list.  And while I have seen ALL of these patterns shipped to production in real life, it doesn't mean that these are by any means the only ones that scream for inclusion.  Anyone got any others?
The Duct Tape Pattern
Its versatility is unmatched – any two bits of code from any two systems can co-operate with the use of this simple pattern.  Need a piece of data from an XML document to display on your page?  No sweat – the Duct Tape Pattern has an implementation that allows you to take data directly from your XML document and slap it straight on the page.  Need to update meta data on a user profile?  Easy as pie – the Duct Tape Pattern affords you the simplicity of running an in-line SQL update statement right in your button click event handler.  Need I say more?
Arguments for Inclusion:
  • When the crap hits the fan, this pattern is used more often (and more consistently) than any other recognized design pattern.
  • If you’re using this pattern, your code isn’t going to be readable, much less maintainable – it’s guaranteed job security.
The Crayola Pattern
Many people confuse the Crayola Pattern for the Facade Pattern, yet they are very different.  While the Facade Pattern attempts to provide a simplified interface to a larger body of code, the Crayola Pattern outright ignores complexity by making wide-sweeping assumptions about the intended usage of the system, thereby making programming against it as simple as coloring with crayons (but you only get to do as many things as you have methods).  The Crayola Pattern is especially effective if you reduce the entire system to 8 method calls, but 64 is also an acceptable practice if you include a UseSharpenerOnBack(object) method in your pattern implementation.
Arguments for Inclusion:
  • Using this pattern will guarantee those who use it to get code comments such as:
            /* we don’t know what this does, but the web server dies when we touch it */
  • Who doesn’t want to write code so sophisticated that nobody else can understand it?  It's a badge of honor to be smarter than everyone else.
The Clipboard Pattern
This is the pattern by which a programmer takes an existing class, copies it to the clipboard, pastes it to a new code file, renames the class, adds one or more properties/methods, and seals the class.  The intent is to make your classes utterly unusable for anything other than the use you originally intended, and utterly bewilder other developers as to why you did it.  The maniacal laugh value never ends!
Arguments for inclusion:
  • Using this pattern adds a LOT of code overhead, and may very well lead to using the Crayola Pattern, which will inevitably lead to using the Duct Tape pattern, which we all know leads to job security.
  • Clipboard Pattern implenters will get to wear out your Ctrl, C, and V keys even faster than your W, S, A, and D keys!
The Shippit Pattern
This is the pattern whereby a programmer copies a block of code from the Internet, pastes it into his code, tweaks it a little, and ships it out to production in one fell swoop.  This revolutionary design pattern has been taking the programming world by storm, slashing costs and boosting productivity across many industry verticals.
Arguments for Inclusion:
  • Saves literally thousands of dollars in development and testing time by simply not doing them.
  • Implementers get to blame someone else for the system not working because they didn't write the code - they simply implemented the Shippit Pattern, and thereby save face when the client can't use the system.
Posted on Monday, October 5, 2009 1:40 PM Humor , Systems Architecture and Design | Back to top

Comments on this post: Design Patterns That Get Implemented in Real Life

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Adam McKee | Powered by: