07.15.07
Design Patterns died today. RIP
SILICON VALLEY, California - Design Patterns (1995-2007) met its untimely demise during a code freeze today. A post by Slashdot user MillionthMonkey shot Design Patterns through the heart. Design Patterns, rest in peace. Design Patterns are survived by Algorithms and Anti Patterns.
I must admit in my 11 years of paid coding, I never used a single Pattern. Yet as I wrote code, I wondered if there was some order to it all. Design Patterns attempts to explain well written code and turn messiness into order. Unfortunately, the explanation was turned on its head, as trend-seeking professors encouraged their students to inject patterns into their code. It sounds like inserting great lines of COBOL into your C program. Sometimes the cure is not right for the disease.
Design Patterns attempt to take the art and science of writing code and turn it into an engineering discipline. Despite arguments to the contrary, computer science is not engineering. Engineering involves applying the same rules (gravity, chemistry, physics) to a large number of experiments and testing their results. Engineers can make predictions based upon scant evidence, like testing a few i-beams or wafers to test the whole, to make assumptions about the quality of a product.
Computer science is not yet engineering. The closest I have seen to real engineering is at Google, where statistics play a role in what they do. At many companies, they test several web page designs on the users to see which one works for the user. This is heading in the right direction. Engineering has little to do with writing code. Writing code in the right way enables good engineering to occur outside the code.
Adding design Patterns to working code to impress your boss creates code bloat. This leads to my favorite Anti Pattern: writing too many design patterns in your code.
Christopher Hogan said,
September 5, 2007 at 3:42 am
One of the primary reasons design patterns exist is to enhance the legibility of a codebase. I’ve seen programmers that beat the dead horse of decorator, and bury their head in the ant hill of command chain patterns. Alas… if they are used correctly / responsibly, OOP Patterns can explicate the conceptual design of a software system effectively, and lay out interface actions without having to develop extensive documentation for systems/ subsystems. In environments where projects are extremely time sensitive, and programmers don’t have time to write external docs due to deadlines, pattern use should assist other programmers by providing a calculated and easily interpretable roadmap in the code itself. Long story short, the code should document itself if you really know what your doing.
As far as code bloat goes, there are solutions to that. Zend Optimizers?
Mod_Gzip? Custom Encoding? I think you can do far more damage with procedural programming, especially when it comes to security bugs.
I honestly can’t tell if this article is trying to be satirical or not, I guess you could call me 4:41am and tired
Cho
http://devf.net