I speak a lot on design patterns. This year, I’ve given nearly a dozen talks on design patterns, relating to my book, Practical Design Patterns in PHP. 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.
Frustrated with your company’s development practices?
You don't have to be!
No matter what the issues are, they can be fixed. You can begin to shed light on these issues with my handy checklist.
Plus, I'll help you with strategies to approach the issues at the organization level and "punch above your weight."