Sankalp Singh Mehra’s Post

Most developers use design patterns. Few know when not to use them. Early in my career, I was obsessed with patterns: Factory, Strategy, Singleton… everywhere. Every problem looked like a chance to “apply a pattern.” Until one day, a simple service turned into: • 6 classes • 3 interfaces • Endless abstraction For a problem that needed… 50 lines of code. ⸻ That’s when it clicked: 👉 Design patterns are tools, not goals. ⸻ Take the Strategy Pattern: Great when: • You have multiple interchangeable behaviors • Logic changes frequently Overkill when: • You have 2 simple conditions • Logic is unlikely to evolve ⸻ What I follow now: • Start simple • Refactor when complexity actually appears • Introduce patterns only when they remove pain ⸻ Big lesson: Bad code ignores patterns. Overengineered code worships them. Good code uses them when needed. ⸻ Before using any pattern, ask: “Am I solving a real problem… or just showing I know this pattern?” ⸻ #DesignPatterns #Java #SoftwareEngineering #CleanCode #BackendDevelopment #SystemDesign

that 6 classes 3 interfaces story is painfully relatable. I went through the exact same phase where every if-else felt like it needed a strategy pattern. the refactor when complexity appears approach is exactly right. YAGNI over premature abstraction every time. the worst offender I see in production codebases is the AbstractSingletonProxyFactoryBean type overengineering where you need to read 8 files to understand what could be one method. start with the simplest thing that works and extract patterns only when you feel the pain of not having them

Like
Reply

To view or add a comment, sign in

Explore content categories