SOLID Principles Explained with Examples [2026]

Q: What does SOLID stand for?

S — Single Responsibility Principle: a class should have only one reason to change. O — Open/Closed Principle: classes should be open for extension but closed for modification. L — Liskov Substitution Principle: objects of a subclass should be replaceable with the parent class without breaking the program. I — Interface Segregation Principle: clients should not be forced to depend on interfaces they do not use. D — Dependency Inversion Principle: high-level modules should not depend on low-level modules; both should depend on abstractions.

Q: What is the Single Responsibility Principle?

A class should do one thing and have one reason to change. If your UserService class handles authentication, sends emails, AND generates PDF reports, any change to PDF generation could break authentication logic. Split into AuthService, EmailService, and ReportService. Benefits: easier testing (smaller units), less coupling, changes are localised. "Reason to change" means stakeholder/actor — if different people/teams need different behaviours, those behaviours should be in different classes.

Q: What is the Open/Closed Principle?

Classes should be open for extension (you can add new behaviours) but closed for modification (you do not change existing code). Achieved through abstractions — instead of modifying a PaymentProcessor class every time a new payment method is added, define a PaymentMethod interface and add new implementations (CreditCard, PayPal, Stripe). The processor never changes; new methods plug in via the interface.

Q: What is the Liskov Substitution Principle?

If S is a subtype of T, then objects of T may be replaced with objects of S without breaking the program. Classic violation: Square extends Rectangle. A rectangle has independent width and height. A square must have equal sides. Setting a Rectangle's width to 5 and height to 3 gives area 15. Doing the same on a Square-as-Rectangle gives area 9 (square overrides setWidth to also set height). The Square breaks the Rectangle contract — it violates LSP.

Q: What is the Dependency Inversion Principle?

High-level modules should not depend on low-level modules; both should depend on abstractions. Instead of UserService directly instantiating MySQLDatabase (tight coupling — hard to test, hard to swap), UserService should depend on a DatabaseInterface. The concrete MySQLDatabase (or MockDatabase in tests) is injected in. This enables Dependency Injection — passing dependencies in from outside rather than creating them internally.

Q: Do I need to follow SOLID strictly in every project?

No — SOLID is guidance, not law. For small scripts or prototypes, strict SOLID adds unnecessary complexity. For long-lived production codebases with teams, SOLID pays dividends. Apply it where the complexity is warranted. The most commonly violated and highest-value principles are Single Responsibility (prevents God classes) and Dependency Inversion (enables testing). Start with those.

SOLID Quick Reference

Letter	Principle	Core Idea
S	Single Responsibility	One class, one reason to change
O	Open/Closed	Extend without modifying existing code
L	Liskov Substitution	Subtypes must honour parent contracts
I	Interface Segregation	Many specific interfaces > one fat interface
D	Dependency Inversion	Depend on abstractions, not concretions

S Single Responsibility Principle

A class should have one reason to change. If multiple stakeholders or concerns drive changes to the same class, split it.

Bad: God class with multiple responsibilities

Violates SRP class UserService { // Responsibility 1: User data access saveUser(user: User): void { /* SQL INSERT */ } getUser(id: number): User { /* SQL SELECT */ } // Responsibility 2: Email sending sendWelcomeEmail(user: User): void { /* SMTP logic */ } sendPasswordResetEmail(user: User): void { /* SMTP logic */ } // Responsibility 3: PDF generation generateUserReport(user: User): Buffer { /* PDF logic */ } } // If SMTP provider changes → UserService changes // If PDF library changes → UserService changes // If database schema changes → UserService changes

Good: Each class has one responsibility

Follows SRP class UserRepository { save(user: User): void { /* SQL INSERT */ } findById(id: number): User { /* SQL SELECT */ } } class EmailService { sendWelcomeEmail(user: User): void { /* SMTP */ } sendPasswordResetEmail(user: User): void { /* SMTP */ } } class UserReportGenerator { generate(user: User): Buffer { /* PDF */ } } // Each class changes for exactly one reason

How to spot SRP violations

If you need to use "and" to describe what a class does ("it handles authentication AND sends emails AND generates reports"), it violates SRP. Each "and" is a separate responsibility.

O Open/Closed Principle

Software entities should be open for extension (add new behaviour) but closed for modification (don't change existing, tested code). New features plug in through abstractions, not if/else chains.

Bad: Modifying the class for every new payment type

Violates OCP class PaymentProcessor { process(payment: Payment): void { if (payment.type === 'credit_card') { // credit card logic } else if (payment.type === 'paypal') { // paypal logic } else if (payment.type === 'stripe') { // stripe logic — added later, modifies existing class } // Every new payment type requires modifying THIS class } }

Good: New payment types extend without modifying

Follows OCP interface PaymentMethod { process(amount: number): void; } class CreditCardPayment implements PaymentMethod { process(amount: number): void { /* credit card logic */ } } class PayPalPayment implements PaymentMethod { process(amount: number): void { /* paypal logic */ } } class StripePayment implements PaymentMethod { process(amount: number): void { /* stripe logic */ } } class PaymentProcessor { process(method: PaymentMethod, amount: number): void { method.process(amount); // never changes } } // Adding Crypto payment: create CryptoPayment class — PaymentProcessor unchanged

L Liskov Substitution Principle

Objects of a subclass must be replaceable by objects of the parent class without breaking the program. Subclasses should honour the behavioural contract of the parent — not weaken preconditions or strengthen postconditions.

Classic violation: Square extends Rectangle

Violates LSP class Rectangle { setWidth(w: number): void { this.width = w; } setHeight(h: number): void { this.height = h; } area(): number { return this.width * this.height; } } class Square extends Rectangle { setWidth(w: number): void { this.width = w; this.height = w; // square must have equal sides } setHeight(h: number): void { this.width = h; this.height = h; } } // Code that works with Rectangle: function testArea(r: Rectangle): void { r.setWidth(5); r.setHeight(3); console.log(r.area()); // expects 15 } testArea(new Rectangle()); // 15 — correct testArea(new Square()); // 9 — WRONG: Square breaks Rectangle's contract

LSP and "is-a" — Geometrically True, Behaviourally False

A square IS geometrically a rectangle. But a Square cannot substitute for a Rectangle in code that relies on independent width/height. LSP is about behavioural substitutability, not taxonomic relationships. When a subclass overrides methods to restrict behaviour, that is an LSP violation.

I Interface Segregation Principle

Clients should not be forced to depend on methods they do not use. A "fat" interface forces implementing classes to implement methods that are irrelevant to them — leading to empty stub implementations.

Violates ISP — fat interface interface Worker { work(): void; eat(): void; // humans eat; robots do not sleep(): void; // humans sleep; robots do not } class RobotWorker implements Worker { work(): void { /* robot works */ } eat(): void { /* EMPTY STUB — robots don't eat */ } sleep(): void { /* EMPTY STUB — robots don't sleep */ } } // Segregated interfaces: interface Workable { work(): void; } interface Feedable { eat(): void; } interface Restable { sleep(): void; } class HumanWorker implements Workable, Feedable, Restable { /* all three */ } class RobotWorker2 implements Workable { work(): void { /* only work */ } }

D Dependency Inversion Principle

High-level modules (business logic) should not depend on low-level modules (database, email, file system). Both should depend on abstractions (interfaces). This enables testing with mock dependencies and swapping implementations.

Violates DIP — tight coupling class UserService { private db = new MySQLDatabase(); // hard-coded dependency private email = new SendGridEmailer(); createUser(data: UserData): void { this.db.insert(data); // cannot test without a real MySQL database this.email.send(data.email, "Welcome!"); } }

Follows DIP — dependency injection interface Database { insert(data: any): void; } interface Emailer { send(to: string, msg: string): void; } class UserService { constructor( private db: Database, // depends on abstraction private email: Emailer // depends on abstraction ) {} createUser(data: UserData): void { this.db.insert(data); this.email.send(data.email, "Welcome!"); } } // Production const service = new UserService(new MySQLDatabase(), new SendGridEmailer()); // Tests — inject mocks, no real DB or email needed const service = new UserService(new MockDatabase(), new MockEmailer());

DIP and Dependency Injection Containers

Frameworks like Spring (Java), Angular (TypeScript), Laravel (PHP), and ASP.NET Core (C#) provide DI containers that automatically wire up dependencies. You define what each class needs (via constructor or annotations) and the framework injects the right implementations — making DIP effortless at scale.

How We Research and Update This Guide

We test the underlying formula or workflow, compare outputs with reliable references, and revise examples whenever the page content changes.

The workflow or formula is tested directly in the tool and compared against independent reference examples.
Examples are kept practical so readers can verify the result without hidden assumptions.
Pages are revised whenever the interface, calculation flow, or surrounding guidance materially changes.

Frequently Asked Questions — SOLID Principles

What does SOLID stand for?

What is the Single Responsibility Principle?

What is the Open/Closed Principle?

What is the Liskov Substitution Principle?

What is the Dependency Inversion Principle?

Do I need to follow SOLID strictly in every project?