The first time I've learnt about OOP Design Patterns was at a Software Engineering introductory course. Since then I had a growing feeling that there is something wrong in the way that the industry treats them.
Don't get me wrong - those patterns exist so that developers wouldn't need to reinvent the wheel each time they encounter a problem that was already solved the problem is that many times developers misunderstand how they were meant to use them.
Design patterns are general reusable solutions to a commonly occurring problems in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.
From Wikipedia on Design Patterns
Several times at my work I would hear the following: "We should use pattern X with pattern Y and then create a..." or "the reason I did X is because that's how pattern Y is implemented". It always seemed to me that those talks were a case of when All you have is a Hammer, Everything Looks Like a nail. People seemed to bend the software so that it would fit the design pattern and not the other way around.
That is why when I saw the post Pattern for Pattern (from The Programmer's Paradox) I felt like someone else share the same frustration I have on the subject.
In the post the author explains how he implemented a design pattern without planning to simply by writing his code to solve a business problem.
I think that all software developers (not to mention architects) would greatly benefit from studying design patterns that exist in the domain of the problem they need to solve but should treat them as a they would treat a code someone else wrote - tae what you need and not just copy paste it as is.
Comments?
Labels: Software Craftmanship, Thoughts