Additionally, patterns have a mixed reputation. On the one hand, they can help to handle complexity. On the other hand, they can create complexity where it is not needed. Sometimes, extracting functions, extracting objects, breaking code up into modules, and depending on a framework (which itself likely exposes and documents patterns of its own) are simpler choices. Keeping the YAGNI (“Ya ain’t gonna need it”) principle in mind and considering the interface you want for your code are the best guidelines when deciding when to implement (or remove) a design pattern.
The good news is that these patterns aren’t that hard to learn and are easy to reference so you don’t have to memorize every detail. Additionally, we’ll focus on just seven of them here, chosen by their likelihood to solve real problems in legacy code. Just learn these seven patterns, and it will change your life!1 Here they are:
As we’re describing fairly high-level changes for most of these patterns, it’s likely that the specific ...