Design patterns to avoid [closed]

Answer 1

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"