Skip to main content

SOLID Principles

One job · Extend, don't change · Subtypes must behave · Small interfaces · Depend on abstractions

That's SOLID in one breath.

S — Single Responsibility Principle (SRP)​

"One class = one reason to change"

A class should do one thing, not many unrelated things.

Bad:

  • Business logic
  • Validation
  • Logging
  • Database access 👉 all in one class

Good:

  • Each concern has its own class

"SRP means a class should have only one responsibility. This makes the code easier to maintain and change, because a change in one requirement only affects one class."

🔍 Example cue​

  • OrderService ≠ OrderService + EmailSender + Logger
  • Split them.

O — Open / Closed Principle (OCP)​

"Add new code, don't edit old code"

🧩 Plain English​

You should be able to add new behavior without touching existing, tested code.

Achieved by:

  • Interfaces
  • Inheritance
  • Polymorphism

​

"OCP means classes should be open for extension but closed for modification. We usually achieve this with interfaces and polymorphism."

🔍 Example cue​

IPaymentProcessor
→ CreditCard
→ PayPal
→ ApplePay

Add new payment → no change to OrderProcessor.

L — Liskov Substitution Principle (LSP)​

"Child must behave like parent"

🧩 Plain English​

If class B inherits from class A, you should be able to replace A with B without breaking logic.

If replacement breaks behavior → ❌ LSP violation.

​

"LSP means derived classes must be substitutable for their base classes without changing correctness."

🔍 Example cue​

Rectangle / Square problem:

  • Square breaks expectations of width/height
  • Inheritance is wrong → composition is better

I — Interface Segregation Principle (ISP)​

"Don't force me to implement what I don't use"

🧩 Plain English​

Interfaces should be small and specific, not "god interfaces".

Bad:

IMachine { Print(); Scan(); Fax(); }

Good:

IPrinter;
IScanner;

​

"ISP means clients shouldn't be forced to depend on methods they don't use. Smaller interfaces improve flexibility."

🔍 Example cue​

Printer shouldn't implement Scan() if it can't scan.

D — Dependency Inversion Principle (DIP)​

"Depend on interfaces, not implementations"

🧩 Plain English​

High-level code should not care about low-level details.

Instead of:

new CreditCardPaymentProcessor();

Use:

IPaymentProcessor;

Usually combined with:

  • Dependency Injection (DI)

​

"DIP means high-level modules depend on abstractions, not concrete implementations. This improves testability and flexibility."

🔍 Example cue​

Mocking in unit tests → DIP in action

🧠 SOLID as a System (Important Insight)​

PrincipleSolves
SRPClasses getting too big
OCPFear of changing existing code
LSPBroken inheritance
ISPFat interfaces
DIPTight coupling

SOLID = maintainable + testable + extensible code

🔗 How SOLID Shows Up in ASP.NET Core​

  • SRP → Controllers thin, logic in services
  • OCP → Strategy pattern, middleware, filters
  • LSP → Correct inheritance (or avoid it)
  • ISP → Small service interfaces
  • DIP → Constructor injection everywhere

45-second Interview Answer (Gold)​

"SOLID is a set of object-oriented design principles that help us build maintainable and extensible systems. SRP keeps classes focused, OCP allows extension without modification, LSP ensures inheritance is used safely, ISP promotes small interfaces, and DIP reduces coupling by depending on abstractions. In ASP.NET Core, these principles naturally align with dependency injection, interfaces, and layered architecture."

❗ Common Interview Mistakes​

❌ Saying SOLID is "rules" ❌ Overengineering everything ❌ Using inheritance everywhere ❌ Confusing DIP with Dependency Injection (DI ≠ DIP)

🧠 Final Memory Trick (Sticky)​

S → One job
O → Extend, don't edit
L → Child ≈ Parent
I → Small interfaces
D → Interfaces everywhere