Friday, July 3, 2009

Why design patterns are dangerous

There are many persons that say pro or against design patterns.

Here is the topic on Wikipedia about them.

What are them: they are specific solutions for Object Oriented paradigm that solves in an elegant/proven way a specific problem.

What is wrong about them? Because programmers whom knows them very well try to match any actual problem to meet the pattern, but not to apply the pattern when it match with pattern's solution.

I will give a small tale regarding this, known as "the needed hammer". There is a need of a software that have two classes, Wall and Nail, to get the Nail in Wall. The architect say: "The design is the following: we will need a hammer. We cannot stop here anyway. A hammer cannot appear by itself. So we need a factory of hammers. This factory of hammers cannot appear in itself, and there can be a shop, another kind of factory, so we need an Abstract factory."

Anyone in fact can say: why do we need more than a hammer? Many software developers want and create very big designs for very simple problems. They would say: what if is not a hammer but another tool to push the nail? And a lot of others: "What if ... ?". The problem is that in most cases this "What if ... " will not happen but the developer will have a huge amount of code that do nothing that create two factories to define an abstract factory.

Also, don't think that I'm the only one who say this. There are more anti-patterns (where patterns fails) than patterns themselves. Look here the article about antipatterns on Wikipedia.

You may argue: the spaghetti code is just because no pattern is used. I cannot disagree more. Spagetti code means mostly tight coupling, which can be fixed with a refactoring as Joel Spolski says. Also, the most concerning in using patterns are not the fact that patterns work, they do, and do it very well, but the problem that peoples try to build things from pattern to pattern. And the patterns themselves are fairly heavy in class numbers, but they mix in most of cases with facade code/proxy code that makes *most* of code to be design code and really few to do something useful.

Do NaroCAD use patterns? Yes, of course, but they come as a result of a specific problem (as we use Pipes and Filters to separate the UI events from UI logic). Can we create a pattern for every class in code!? Most probably we can but we are not gonna fix it.

No comments: