Design patterns to avoid [closed]

Question

A lot of people seem to agree, that the Singleton pattern has a number of drawbacks and some even suggest avoiding the pattern entirely. There's an excellent discussion here. Please direct any comments about the Singleton pattern to that question.

My question: Are there other design patterns, that should be avoided or used with great care?

Answer 1

I don't think you should avoid Design Patterns (DP), and I don't think you should force yourself to use DPs when planning your architecture. We should only use DPs when they natural emerge from our planning.

If we define from the start that we want to use a given DP, many of our future design decisions will be influence by that choice, with no guarantee that the DP we chose is suited for our needs.

One thing we also shouldn't do is treat a DP as an immutable entity, we should adapt the pattern to our needs.

So, sumarizing, I don't think we should avoid DPs, we should embrace them when they are already taking shape in our architecture.

Answer 2

I believe the Template Method pattern generally is a very dangerous pattern.

• A lot of times it uses up your inheritance hierarchy for "the wrong reasons".
• Base classes have a tendency to become littered with all sorts of unerelated code.
• It forces you to lock down design, often quite early in the development process. (Premature lock down in a lot of cases)
• Changing this at a later stage becomes just harder and harder.

Answer 3

Iterator is one more GoF pattern to avoid, or at least to use it only when none of alternatives are available.

Alternatives are:

1. for-each loop. This construction is present in most mainstream languages and may be used to avoid iterators in majority of cases.

2. selectors à la LINQ or jQuery. They should be used when for-each is not appropriate because not all of objects from container should be processed. Unlike iterators, selectors allow to manifest in one place what kind objects is to be processed.

Answer 4

A complement to Spoike's post, Refactoring to Patterns is a good read.

Answer 5

It is simple ... avoid Design Patterns that are not clear to you or those that you do not feel comfortable in.

To name some ...

there are some unpractical patterns, like e.g.:

• Interpreter
• Flyweight

there are also some harder to grasp, like e.g.:

• Abstract Factory - Full abstract factory pattern with families of created objects is not such a breeze as it seems to be
• Bridge - Can get too abstract, if abstraction and implementation are divided to subtrees, but is very usable pattern in some cases
• Visitor - Double dispatch mechanism understanding is really a MUST

and there are some patterns that look terribly simple, but are not so clear choice because of various reasons related to their principle or implementation:

• Singleton - not really totally bad pattern, just TOO overused (often there, where it is not suitable)
• Observer - great pattern ... just makes code much harder to read and debug
• Prototype - trades compiler checks for dynamism (which can be good or bad ... depends)
• Chain of responsibility - too often just forcedly/artificially pushed into the design

For those "unpractical ones", one should really think about before using them, because there is usually more elegant solution somewhere.

For the "harder to grasp" ones ... they are really great help, when they are used at suitable places and when they are implemented well ... but they are nightmare, when improperly used.

Now, what's next ...

• Head First Design Patterns is a MUST
• Sourcemaking is the "first aid"

Answer 6

Some say that service locator is an anti pattern.