LLD Design Patterns: What Problems Does SOLID Actually Solve?

In the previous article, we discovered an important idea: SOLID principles make our designs better, but they don't eliminate every design problem. That naturally raises another question. If SOLID isn't the complete answer, then what is it actually designed to solve? Many developers know the five SOLID principles by name. They can even define SRP, OCP, or DIP during interviews. Yet when asked "Why was SOLID created?", the answers are often vague. That's because SOLID is sometimes treated as a checklist instead of a design philosophy. Before we move into Design Patterns, let's understand exactly what SOLID helps us achieve—and just as importantly, what it was never intended to solve. Why SOLID Was Introduced Imagine you're building an online food delivery application. Initially, there's only one restaurant, one payment method, and one delivery partner. The system is small. Adding new features is easy. Now imagine the business grows. New payment gateways are added. Different delivery partners have different pricing rules. Notifications need to support Email, SMS, Push, and WhatsApp. Discount engines become more sophisticated. Without a disciplined design approach, the codebase slowly starts showing familiar symptoms: Large classes handling multiple responsibilities Frequent modifications to existing code Tight coupling between unrelated components Difficult unit testing Fear of making changes SOLID was introduced to reduce exactly these kinds of problems. Its goal is simple: Help software remain maintainable as it grows. SOLID Helps You Design Better Building Blocks Think of constructing a city. Every building should have a clear purpose. Hospitals shouldn't also function as schools. Police stations shouldn't operate restaurants. Libraries shouldn't process tax returns. Each building becomes easier to understand, maintain, and improve. SOLID applies the same thinking to software. Instead of asking: "Can this class do one more thing?" It encourages us to ask: "Should this class be responsible for this at all?" Good software isn't built by making individual classes powerful. It's built by making responsibilities clear. The Five Problems SOLID Addresses Rather than memorizing five definitions, think of SOLID as five recurring design concerns. 1. Keeping Responsibilities Focused When one class handles multiple unrelated jobs, every new requirement makes it more fragile. SOLID encourages separating responsibilities so each class has one clear reason to change. 2. Making Software Easier to Extend Business requirements constantly evolve. Instead of repeatedly modifying existing classes, SOLID encourages designs where new behavior can be added through extension. This reduces the risk of accidentally breaking existing functionality. 3. Making Inheritance Safe Inheritance is powerful—but only when child classes truly behave like their parents. SOLID encourages designs where replacing one implementation with another doesn't produce surprising behavior. This keeps polymorphism reliable. 4. Preventing Bloated Interfaces Not every consumer needs every capability. Large interfaces force classes to depend on methods they don't actually use. Smaller, focused interfaces reduce unnecessary dependencies and make systems easier to understand. 5. Reducing Direct Dependencies High-level business logic shouldn't depend on low-level implementation details. Instead, both should depend on abstractions. This makes systems easier to test, replace, and evolve over time. A Pattern Begins to Emerge Notice something interesting. Every SOLID principle is improving how individual classes are designed and connected. They're teaching us things like: Who owns a responsibility? What should this class know? What should it depend on? How can it remain easy to change? These are incredibly important questions. But they're all focused on designing good components. What SOLID Doesn't Try to Answer Suppose your application now supports multiple payment gateways. A new question appears: Who should decide which payment object to create? Or imagine users can receive notifications through Email, SMS, Push, or WhatsApp. Now another question appears: How should the system choose the correct notification behavior at runtime? Or consider integrating with an external shipping provider. Another question emerges: How should two incompatible systems communicate without changing either one? These aren't questions about responsibilities. They're not questions about interfaces. They're not questions about dependencies. They're different kinds of design problems. And that's perfectly okay. Because SOLID was never designed to answer them. Weak Thinking vs Strong Thinking Weak Thinking "SOLID should solve every design problem." Strong Thinking "SOLID solves a specific category of design problems. Other recurring problems require different design techniques." Understanding this distinction is what separates someone who knows the principles from someone who understands software design. Common Beginner Mistake A common misconception is: "If I apply all five SOLID principles, I won't need Design Patterns." This isn't true. Design Patterns don't replace SOLID. They assume you've already built a good foundation using principles like SOLID. You can think of it this way: SOLID improves the quality of your building blocks. Design Patterns help organize those building blocks to solve recurring architectural challenges. They're complementary, not competing, ideas. Interview Perspective Interviewers rarely ask: "What does the O in SOLID stand for?" Instead, they often present a design scenario and observe your reasoning. They're looking for answers like: Why is this responsibility misplaced? Why is this dependency problematic? Why is this design becoming difficult to extend? If your thinking naturally reflects SOLID principles, you won't need to force the terminology into the conversation. The design itself will demonstrate your understanding. Key Insight SOLID isn't a universal solution for every software design challenge. It provides principles for creating maintainable, flexible, and well-structured components. As systems evolve, new categories of recurring problems emerge—and those are the problems Design Patterns were created to address. In This Article, You Learned Why SOLID was introduced. The types of design problems SOLID is meant to solve. Why SOLID focuses on building good components. Why some recurring design problems naturally fall outside SOLID's scope. One-Line Takeaway SOLID teaches you how to build maintainable components—it doesn't attempt to solve every recurring design challenge in software.