SOLID Principles

SOLID is an acronym for five object-oriented design principles — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion — that guide developers toward code that is easier to maintain, extend, and test.

What It Really Means

SOLID is not about writing more code or adding complexity. It is about writing code that does not fight you when requirements change. Every codebase that survives long enough will face changes: new features, new integrations, bug fixes, performance optimizations. SOLID principles reduce the blast radius of those changes.

Robert C. Martin introduced these principles in the early 2000s. They are not rules to follow blindly — they are heuristics. A 200-line script does not need SOLID. A 200,000-line codebase that ignores them will eventually slow to a crawl because every change ripples through coupled components.

The principles work together. Dependency Inversion enables the Open/Closed Principle. Interface Segregation supports Single Responsibility. Liskov Substitution ensures polymorphism actually works. Understanding each principle in isolation is useful; understanding how they reinforce each other is powerful.

How It Works in Practice

S — Single Responsibility Principle (SRP)

"A class should have only one reason to change."

SRP does not mean "one method per class." It means one reason to change. If the email provider changes, only EmailSender changes. If the PDF layout changes, only PdfFormatter changes.

O — Open/Closed Principle (OCP)

"Software entities should be open for extension but closed for modification."

L — Liskov Substitution Principle (LSP)

"Objects of a superclass should be replaceable with objects of a subclass without breaking the program."

LSP violations create bugs where substituting a subclass silently changes behavior.

I — Interface Segregation Principle (ISP)

"No client should be forced to depend on methods it does not use."

D — Dependency Inversion Principle (DIP)

"Depend on abstractions, not concretions."

Implementation

Applying all five principles together:

Trade-offs

Benefits:

• Changes are localized: modifying one feature does not ripple across the codebase
• Testing is easier: mock interfaces instead of concrete implementations
• New features are additive: extend with new classes rather than modifying existing ones
• Teams can work in parallel on different implementations of the same interface

Costs:

• More abstractions, more files, more indirection
• Over-engineering risk for simple applications
• Interface explosion if ISP is applied too aggressively
• Learning curve for developers unfamiliar with abstraction-heavy design

When to apply SOLID rigorously:

• Large codebases (50k+ lines) with multiple developers
• Long-lived applications (3+ years of active development)
• Systems with frequently changing business rules
• Libraries and frameworks consumed by other teams

When to relax SOLID:

• Scripts, prototypes, and throwaway code
• Small services with stable requirements
• Performance-critical hot paths where abstraction overhead matters

Common Misconceptions

• "SRP means a class should do one thing" — SRP means a class should have one reason to change. A class can have multiple methods as long as they all change for the same reason (same stakeholder, same business concern).
• "SOLID means you need interfaces for everything" — Only create interfaces at boundaries where substitutability matters. Internal helper classes do not need interfaces.
• "SOLID is only for object-oriented languages" — The principles apply to functions, modules, and packages too. A function should have a single responsibility. A module should depend on abstractions.
• "Following SOLID makes code good" — SOLID prevents specific categories of maintenance problems. It does not guarantee readable code, correct algorithms, or good performance. It is a necessary but not sufficient condition for quality.
• "Liskov Substitution only matters for inheritance" — LSP applies anywhere you use polymorphism: interfaces, duck typing, generics. Any place where you substitute one implementation for another.

How This Appears in Interviews

1. "Explain SOLID principles with examples" — Walk through each principle with a before/after code example. Interviewers want to see that you understand the why, not just the definition.
2. "How would you refactor this code?" — Look for SRP violations (classes doing too much), DIP violations (hardcoded dependencies), and OCP violations (switch statements for types).
3. "How do you make code testable?" — Dependency Inversion: inject interfaces, mock at boundaries. This is the most practically impactful SOLID principle.
4. "What is the difference between DI (Dependency Injection) and DIP (Dependency Inversion)?" — DIP is the principle (depend on abstractions). DI is a technique for implementing DIP (inject dependencies through constructors).

Related Concepts

• Clean Architecture — applies SOLID principles to system-level design
• Observer Pattern — implements OCP by allowing new observers without modifying the subject
• Anti-Corruption Layer — applies DIP at system boundaries
• Interview Questions: Object-Oriented Design
• System Design Interview Guide
• Algoroq Pricing — access all concept deep-dives