I think many developers apply design patterns backwards: memorize the catalog, then go looking for places to apply them, resulting in over-engineered code.
And from what I've seen, AI appears to repeat that same mistake.
I've read an article by Alina Kovtun about a better approach: start with the friction, then find the right pattern.
🔗 LINK: "Stop Memorizing Design Patterns: Use This Decision Tree Instead" https://lnkd.in/gxqPGyiv
She published a decision-tree framework that boils pattern selection down to three questions:
👉 Is the pain about creating objects?
👉 Is the pain about how objects fit together?
👉 Is the pain about behavior that changes across cases or over time?
Brooks Johnson has created an open-source repo (🔗 LINK: "Design-Patterns-In-Apex" https://lnkd.in/gfhDJbyR) with GoF patterns implemented in Apex.
Here's a short version of Alina's decision tree applied to Brooks' Apex patterns:
👉 Creation pain:
Too many constructor params -> Builder
"Which class do I instantiate?" -> Simple Factory, Factory Method, or Reflective Factory
Need one shared instance -> Singleton
👉 Structure pain:
Incompatible interfaces -> Adapter
Layering on behavior without creating many subclasses -> Decorator
Two dimensions of change tangled together -> Bridge
👉 Behavior pain:
Giant If/else to handle all variants -> Strategy
Behavior depends on state -> State
One change, many reactors -> Observer
New operations on a stable structure -> Visitor
One step before deciding on a design pattern: refactor first. Clean up what you have before using a pattern and that should help make obvious the need for a pattern - or maybe even not need a pattern.
