Inscrivez-vous ou connectez-vous pour rejoindre votre communauté professionnelle.
One of the questions I get the most often about design patterns is, “how do I pick a design pattern to use in my project?”
My answer is always the same: you don’t.
It’s a common misconception that you pick a design pattern before writing code to solve your problem. More often than not, the pattern will pick you: by the way you go about solving the problem, or the way you approach the architecture. But picking a design pattern first more often than not leads to over-architecture of your application.
That’s not to say that you shouldn’t do any design; far from it. Designing your application, the objects and the interactions between those objects is likely to reveal a design pattern that you can use. The problems show up when you select the pattern first, before you do any of the design work or go through the thought process.
Once you’ve got a solution or an architecture in hand, and you have identified a compatible design pattern, then you can go about the work of more fully implementing the pattern overall. You’ll end up with a much better application overall, with less complexity.
