SOLID violations and fixes in LLD - Deep Dive

Overview - SOLID violations and fixes

What is it?

SOLID is a set of five design principles that help create software that is easy to understand, maintain, and extend. Violations of these principles cause code to become messy, hard to change, and error-prone. Fixing these violations improves the structure and quality of software. This topic explains common mistakes against SOLID and how to correct them.

Why it matters

Without SOLID principles, software becomes fragile and difficult to update, leading to bugs and wasted time. Teams struggle to add features or fix issues because the code is tangled and unclear. Applying SOLID helps developers build systems that grow smoothly and stay reliable, saving effort and frustration.

Where it fits

Learners should know basic programming and object-oriented concepts before this. After understanding SOLID violations and fixes, they can explore design patterns, refactoring techniques, and architecture best practices.

Mental Model

Core Idea

SOLID principles guide how to organize code so each part has a clear, single job and changes don’t break other parts.

Think of it like...

Imagine a well-organized kitchen where each tool has its place and purpose; if you mix everything together, cooking becomes slow and frustrating. SOLID keeps code like that kitchen—tidy and efficient.

┌───────────────┐
│   SOLID Code  │
├───────────────┤
│ S: Single Job │
│ O: Open/Closed│
│ L: Liskov Sub │
│ I: Interface  │
│ D: Dependency │
└─────┬─────────┘
      │
      ▼
┌─────────────────────────────┐
│ Violations cause:            │
│ - Mixed responsibilities    │
│ - Fragile changes           │
│ - Tight coupling            │
└─────────────────────────────┘
      │
      ▼
┌─────────────────────────────┐
│ Fixes restore:               │
│ - Clear roles               │
│ - Easy extension            │
│ - Loose connections        │
└─────────────────────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Single Responsibility Principle

Concept: Introduce the idea that each module or class should have only one reason to change.

The Single Responsibility Principle (SRP) means a class or module should do one thing only. For example, a class that handles user data should not also handle sending emails. Mixing these jobs makes code confusing and hard to fix.

Result

Code with SRP is easier to read and change because each part has a clear job.

Understanding SRP helps prevent tangled code where one change breaks many things.

2

Foundation

Grasping Open/Closed Principle Basics

Concept: Learn that software entities should be open for extension but closed for modification.

Open/Closed Principle (OCP) means you can add new features without changing existing code. For example, adding a new payment method should not require changing the payment processing class, but extending it.

Result

Systems following OCP can grow without breaking existing functionality.

Knowing OCP reduces bugs caused by changing tested code.

3

Intermediate

Detecting Violations of Liskov Substitution

🤔Before reading on: do you think a subclass can always replace its parent without issues? Commit to yes or no.

Concept: Liskov Substitution Principle (LSP) means subclasses should behave like their parents without surprises.

If a subclass changes expected behavior, like throwing errors where the parent does not, it violates LSP. For example, a Square class inheriting from Rectangle but restricting width and height independently breaks LSP.

Result

Violations cause unexpected bugs when using subclasses in place of parents.

Recognizing LSP violations prevents subtle bugs in inheritance hierarchies.

4

Intermediate

Fixing Interface Segregation Violations

🤔Before reading on: is it better for clients to depend on large interfaces or small, specific ones? Commit to your answer.

Concept: Interface Segregation Principle (ISP) says clients should not be forced to depend on methods they don't use.

If an interface has many unrelated methods, clients implementing it must provide unnecessary code. Splitting interfaces into smaller ones tailored to client needs fixes this.

Result

Clients become simpler and less affected by changes in unrelated methods.

Understanding ISP improves modularity and reduces ripple effects of changes.

5

Intermediate

Recognizing Dependency Inversion Violations

🤔Before reading on: should high-level modules depend on low-level modules or abstractions? Commit to your answer.

Concept: Dependency Inversion Principle (DIP) means high-level modules depend on abstractions, not concrete details.

When high-level code directly depends on low-level implementations, changes in details break the whole system. Using interfaces or abstract classes to invert dependencies fixes this.

Result

Code becomes more flexible and easier to test.

Knowing DIP helps build systems that adapt to change without rewriting core logic.

6

Advanced

Refactoring to Fix SRP Violations

🤔Before reading on: do you think splitting a class with multiple jobs into smaller classes helps or complicates the design? Commit to your answer.

Concept: Learn how to identify and split classes that do too many things into focused classes.

For example, a UserManager class that handles user data and email notifications should be split into UserDataHandler and EmailNotifier. This reduces dependencies and clarifies responsibilities.

Result

Code becomes easier to maintain and extend with less risk of bugs.

Knowing how to refactor SRP violations improves long-term code health.

7

Expert

Advanced Fixes for LSP and DIP Violations

🤔Before reading on: can you think of cases where fixing LSP or DIP might introduce complexity? Commit to your answer.

Concept: Explore complex scenarios where fixing LSP or DIP requires design patterns like Adapter or Dependency Injection.

For example, to fix LSP violation in a Square-Rectangle hierarchy, use composition instead of inheritance. To fix DIP violations, apply Dependency Injection frameworks to manage abstractions and implementations cleanly.

Result

Systems become robust and flexible but require careful design to avoid over-engineering.

Understanding these advanced fixes helps balance design purity with practical complexity.

Under the Hood

SOLID principles work by guiding how code modules depend on each other and how responsibilities are divided. Internally, this reduces tight coupling and increases cohesion. For example, Dependency Inversion uses abstract interfaces so that high-level modules do not rely on concrete implementations, enabling easier swapping and testing. Violations cause tangled dependencies and unpredictable side effects.

Why designed this way?

SOLID was designed to solve common problems in object-oriented design: fragile code, difficulty in adding features, and high bug rates. Early software often mixed responsibilities and tightly coupled modules, making maintenance costly. SOLID principles emerged as a set of best practices to create flexible, maintainable, and scalable software.

┌───────────────┐
│   Client Code │
└──────┬────────┘
       │ depends on
┌──────▼────────┐
│  Abstraction  │
└──────┬────────┘
       │ implemented by
┌──────▼────────┐
│ Concrete Code │
└───────────────┘

Violations:
- Client depends on Concrete Code directly
- Classes do multiple jobs
- Subclasses change expected behavior

Myth Busters - 4 Common Misconceptions

Quick: Does a class with multiple methods always violate SRP? Commit yes or no.

Common Belief: Many think SRP means a class can only have one method.

Reality: SRP means a class should have one reason to change, not just one method. Multiple related methods are fine if they serve a single responsibility.

Why it matters: Misunderstanding SRP leads to unnecessary fragmentation, making code harder to navigate.

Quick: Is it okay to change existing code to add new features if tests cover it? Commit yes or no.

Common Belief: Some believe OCP means you must never change existing code.

Reality: OCP means you should avoid changing existing code when possible, but sometimes small changes are necessary and safe if well-tested.

Why it matters: Rigidly avoiding changes can lead to overcomplicated designs or duplicated code.

Quick: Can inheritance always replace composition for code reuse? Commit yes or no.

Common Belief: Inheritance is always better for reusing code and fixing LSP violations.

Reality: Composition often better respects LSP and leads to more flexible designs than inheritance.

Why it matters: Misusing inheritance causes fragile hierarchies and subtle bugs.

Quick: Does depending on abstractions mean you should never use concrete classes? Commit yes or no.

Common Belief: Some think DIP forbids any use of concrete classes in high-level code.

Reality: DIP encourages depending on abstractions but concrete classes are used at runtime, often injected or instantiated outside high-level modules.

Why it matters: Misunderstanding DIP leads to over-abstraction and unnecessary complexity.

Expert Zone

1

Fixing SOLID violations sometimes introduces more classes and interfaces, which can increase complexity if not managed carefully.

2

Balancing SOLID principles with YAGNI (You Aren't Gonna Need It) is crucial; over-applying SOLID can lead to premature optimization.

3

Dependency Injection frameworks help manage DIP but require understanding lifecycle and scope to avoid memory leaks or hidden dependencies.

When NOT to use

In very small or simple projects, strict SOLID adherence may overcomplicate code. Alternatives include simpler procedural code or minimal object orientation. Also, in performance-critical systems, some SOLID abstractions might add overhead.

Production Patterns

In real systems, SOLID principles guide microservices design, plugin architectures, and test-driven development. For example, Interface Segregation helps define clear API boundaries, and Dependency Inversion enables mocking dependencies in tests.

Connections

Modular Programming

SOLID principles build on modular programming ideas by focusing on module responsibilities and dependencies.

Understanding modular programming helps grasp why SOLID emphasizes single responsibility and loose coupling.

Lean Manufacturing

Both SOLID and lean manufacturing aim to reduce waste and improve flow by clear roles and minimizing dependencies.

Seeing SOLID as a lean process for code helps appreciate its focus on efficiency and adaptability.

Human Cognitive Load Theory

SOLID reduces cognitive load by breaking code into understandable parts, similar to how cognitive load theory advises chunking information.

Knowing cognitive load theory explains why SOLID code is easier to read and maintain.

Common Pitfalls

#1 Combining unrelated responsibilities in one class.

Wrong approach:

class UserManager {
void saveUser() { /* save user */ }
void sendEmail() { /* send email */ }
}

Correct approach:

class UserDataHandler {
void saveUser() { /* save user */ }
}
class EmailNotifier {
void sendEmail() { /* send email */ }
}

Root cause:

Misunderstanding SRP leads to mixing concerns, causing fragile and hard-to-maintain code.

#2 Changing existing classes to add new features directly.

Wrong approach:

class PaymentProcessor {
void processCreditCard() { /* code */ }
void processPaypal() { /* code added later */ }
}

Correct approach:

interface PaymentMethod {
void pay();
}
class CreditCardPayment implements PaymentMethod { /* code */ }
class PaypalPayment implements PaymentMethod { /* code */ }
class PaymentProcessor {
void process(PaymentMethod method) { method.pay(); }
}

Root cause:

Ignoring OCP causes code changes that risk breaking existing features.

#3 Subclass changes parent behavior breaking expectations.

Wrong approach:

class Rectangle {
int width, height;
void setWidth(int w) { width = w; }
void setHeight(int h) { height = h; }
}
class Square extends Rectangle {
void setWidth(int w) { width = height = w; }
void setHeight(int h) { width = height = h; }
}

Correct approach:

class Rectangle {
int width, height;
void setWidth(int w) { width = w; }
void setHeight(int h) { height = h; }
}
class Square {
int side;
void setSide(int s) { side = s; }
}

Root cause:

Misusing inheritance breaks LSP, causing unexpected behavior.

Key Takeaways

SOLID principles guide how to write code that is easy to maintain, extend, and understand by assigning clear responsibilities and managing dependencies.

Violations of SOLID cause fragile, tangled code that is hard to change without breaking other parts.

Fixing SOLID violations often involves splitting classes, using interfaces, and applying design patterns like Dependency Injection.

Understanding the balance between SOLID and practical complexity is key to writing effective software.

SOLID principles connect deeply with concepts in modularity, lean processes, and human cognition, making them powerful tools beyond just code.