The SOLID principles are a set of five design principles in Object-
Oriented Design (OOD) aimed at creating software that is modular,
flexible, and maintainable. These principles help developers write code
that is easier to manage, extend, and debug. Each letter in SOLID
represents a key principle:
1. S — Single Responsibility Principle (SRP)
Definition:
A class should have only one reason to change. In other
words, each class should have one responsibility or
functionality.
Why:
o Makes the code easier to maintain and debug.
o Increases readability and modularity.
Example:
Consider a Library Management System:
class Book {
public string Title { get; set; }
public string Author { get; set; }
class BookDatabase {
public void SaveBook(Book book) {
// Code to save book to the database
class BookPrinter {
public void PrintBookDetails(Book book) {
[Link]($"{[Link]} by {[Link]}");
✅ Good Practice:
Book class handles book information.
BookDatabase manages saving to the database.
BookPrinter is responsible for printing details.
2. O — Open/Closed Principle (OCP)
Definition:
Software entities (classes, functions, modules) should be open
for extension but closed for modification.
Why:
o Prevents breaking existing functionality when adding new
features.
o Encourages the use of abstractions and interfaces.
Example:
Consider a Payment System:
interface IPaymentMethod {
void ProcessPayment();
class CreditCardPayment : IPaymentMethod {
public void ProcessPayment() {
[Link]("Processing Credit Card Payment...");
}
class PayPalPayment : IPaymentMethod {
public void ProcessPayment() {
[Link]("Processing PayPal Payment...");
class PaymentProcessor {
public void Process(IPaymentMethod paymentMethod) {
[Link]();
✅ Good Practice:
You can add new payment methods (e.g., CryptoPayment)
without changing existing code.
3. L — Liskov Substitution Principle (LSP)
Definition:
Subtypes must be substitutable for their base types. If S is a
subtype of T, objects of type T should be replaceable with objects
of type S without breaking the system.
Why:
o Prevents unexpected behavior when using derived classes.
Example:
class Rectangle {
public virtual int Width { get; set; }
public virtual int Height { get; set; }
public int Area() => Width * Height;
}
class Square : Rectangle {
public override int Width {
set { [Link] = [Link] = value; }
public override int Height {
set { [Link] = [Link] = value; }
❌ Bad Practice:
A square doesn’t behave like a rectangle — setting width
changes the height, violating LSP.
✅ Solution:
Use separate classes for Square and Rectangle.
4. I — Interface Segregation Principle (ISP)
Definition:
Clients should not be forced to depend on interfaces they do not
use.
Why:
Avoids bloated, difficult-to-maintain interfaces.
Example:
interface IPrinter {
void PrintDocument();
}
interface IScanner {
void ScanDocument();
class Printer : IPrinter {
public void PrintDocument() {
[Link]("Printing Document...");
class Scanner : IScanner {
public void ScanDocument() {
[Link]("Scanning Document...");
✅ Good Practice:
Separate interfaces ensure that classes implement only what
they need.
5. D — Dependency Inversion Principle (DIP)
Definition:
High-level modules should not depend on low-level modules;
both should depend on abstractions.
Why:
o Promotes loose coupling and flexibility.
Example:
interface ILogger {
void Log(string message);
class FileLogger : ILogger {
public void Log(string message) {
[Link]($"Logging to file: {message}");
class Application {
private readonly ILogger _logger;
public Application(ILogger logger) {
_logger = logger;
public void Run() {
_logger.Log("Application is running.");
✅ Good Practice:
The Application class depends on the ILogger abstraction,
allowing for flexibility (e.g., switch to DatabaseLogger).