How to Choose a Design Pattern That Fits

Me:[^]

Design Patterns are like programming languages:
They don't solve your problem by themselves, neither they guaranty that your design decisions are an appropriate solution for the problem. Stick with a design pattern you like, and most important, understand.
Another fault that seems to happen very often is that people pick a design pattern and then later start to abandon it, and switch to another one - Which leads to crapcode and mass confusion, sooner or later.

Quote:

Choosing a Design Pattern[^]
Patterns are not the panacea of program design. They do not replace traditional object-oriented analysis techniques like CRC cards or use-case modeling. To use an architectural analogy, analysis lets you determine that your house needs 200 amps of electricity. Patterns let you determine how the wiring will be installed.
Patterns do help you think about the problems you may encounter while designing a system. Therefore, a generic, pattern-based solution is often more robust than a solution designed by one individual to solve a specific problem.
Given the number of design patterns in common use (as well as many more being invented and discovered almost daily) it can sometimes be hard to choose the pattern that suits your needs.
The first thing you should decide is whether the problem is fundamentally creational, structural, or behavioral. Some problems, of course, have aspects of two or even three, and may require you to mix and match patterns.