When are design patterns the problem instead of the solution? [closed]

Answer 1

I recall an interview with one of the GoF where someone asked about the common claim that design patterns are tools to replace features which are missing from a language. The author argued that A) any language has design patterns (not the same ones) since design patterns are tools built to work around language idiosynchrasies and B) it is not feasible to get rid of their need by adding more features to a language.

Answer 2

Come on folks, please read the whole quote, read it carefully. Or even better, read the essay.

Paul Graham criticizes, among other things, C-like languages for not providing adequate means of abstraction. Within the scope of the essay his criticism of patterns is an afterthought, or rather a case-in-point for his main argument. His reasoning goes like this:

It is logical to use common strategies to solve recurring problems. In really abstract languages it is possible to formalize those strategies and put them into a library. Whenever you need to use them, you merely #include them, instantiate them, expand them, or whatever. C-like languages in contrast do not provide the necessary means of abstraction. That is witnessed by the fact that there exists something like "patterns". A pattern is such a common strategy that cannot be expressed by library code and thus has to be expressively written every time it is applied.

Paul Graham does not think that patterns are evil by themselves. They are a symptom of languages that fall short in providing means of abstraction. In that respect he is almost certainly right. Whether we should use different languages because of that, is of course another discussion.

The original poster of the question, on the other hand, is wrong: Patterns are not "symptoms of not having not enough abstraction in your code", but are symptoms of having not enough means of abstraction in your language.

Answer 3

In a nutshell patterns are just formalized ways of solving common tasks in various languages. As such there were "design patterns" even before someone coined the term. For every language there are "best practices" and design patterns are really just that - a set of best practices for problems that occur on a regular basis.

One of the main benefits of labeling the patterns is that the shared terminology allows us to talk about abstract concepts.

Obviously design patterns can be misapplied or overused in any given context, but I really fail to see how design patterns as a concept can be a problem.

Answer 4

I don't think the patterns per se are the problem, but rather the fact that developers can learn patterns and then overapply them, or apply them in ways that are wildly inappropriate.

The use of patterns is something that experienced programmers just learn naturally. You've solved some problem X many times, you know what approach works, you use that approach because your skill and experience tell you it's appropriate. That's a pattern, and it's okay.

But it's equally possible for a programmer who's less skilled to find one way to do things and try to cram every problem they come across into that mold, because they don't know any other way. That's a pattern too, and it's evil.

Answer 5

The shape of a program should reflect only the problem it needs to solve.

And what happens when requirements change and your module wasn't abstracted using a Facade or potentially a Mediator, thus making it overly difficult to swap out?

design patterns are a sign of not enough abstraction

Chances are, if you've abstracted everything properly, then you have a design pattern in there somewhere.

What if there is an extremely 'heavy' object that does not have to be loaded? The Proxy pattern saves the user from waiting forever.

I could go on, but I think I have said enough. Design patterns are great tools when used correctly. The problem comes when they are used improperly, but I guess that's why misused patterns are called anti-patterns.

Answer 6

When I programmed in LISP I didn't use GoF design patterns at all, it just was not applicable for the programs that I was writing. Now I'm programming in C# and run across situations all the time where a design pattern actually simplifies the program being written.