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

Answer 1

There are a lot of maxims we use (and which are common around SO) that, if you trace them back to the source, originally were asserted with reservations; as in " ... when you are developing using ..." This is one of those cases. Patterns fit well when you are doing OOP. YMMV when you are in another paradigm.

"Refactoring" is another similar case.

When I'm writing SQL, the "patterns" part of my brain switches off.

Note in your quotation: "I'm generating by hand the expansions of some macro that I need to write.". So he recognizes patterns and abstracts them into a macro - he doesn't recode it another way. Just good-ol' DRY. It's not the patterns, it's failing to do the right thing with the ones we find. I'd say his comment could go into any wiki entry expanding on the virtues of DRY, and how to own them. GoF would concur completely - recognize the desgin patterns, then use what you know about them to implement (or refactor) them appropriately.

Answer 2

My problem with patterns is that there seems to be a central lie at the core of the concept: The idea that if you can somehow categorize the code experts write, then anyone can write expert code by just recognizing and mechanicaly applying the categories. That sounds great to managers, as expert software designers are relatively rare.

The problem is that it isn't true. You can't write expert-quality code with only "design patterns" any more than you can design your own professional fashion designer-quality clothing using only sewing patterns.

Answer 3

There is never a need to use design patterns—you can always write code that ignores everything that has been learned about coding up to now—it may even work. But design patterns can make things easier, giving you a shared language for discussing design.

Diesign patterns don't represent too little abstraction—they are an attempt to increase the level of abstraction. You can say "this bit is a Visitor" rather than "here is some code that recursively traverses a tree of objects, performing on operation on them."

Answer 4

I would rather work with too many patterns than none at all. That said, the proper balance is of course the goal.

Answer 5

I think that sometimes when you learn a pattern, you don't just learn the pattern. But you aquire a new view at the problem domain which you might not have had before. And maybe its exactly what you wanted.

Without context for the "problem" we can't say if design patterns are the solution or not.

Answer 6

Design Patterns are solutions for common problems.

But first, you need to know what or where is the problem. And that's the point where people fail to use the patterns correctly.