SOLID Principles with Examples

SOLID Principles

The SOLID principles are five foundational guidelines for object-oriented software design that help developers write code that is more maintainable, flexible, and scalable ¹ ² ³. Please check the citations at the end of the page if you want to read in depth about SOLID principles. Below is a very short description of each. Then we dive into the examples which are more useful than the descriptions!

Single Responsibility Principle (SRP):
Each class should have only one reason to change, meaning it should handle a single, well-defined responsibility ⁴ ² ⁵ ³.
Open/Closed Principle (OCP):
Software entities should be open for extension but closed for modification. You should be able to add new functionality without altering existing code ¹ ² ⁵ ³.
Liskov Substitution Principle (LSP):
Subtypes must be substitutable for their base types. Objects of a derived class should be usable wherever objects of the base class are expected, without affecting program correctness ² ⁵ ³.
Interface Segregation Principle (ISP):
Clients should not be forced to depend on interfaces they do not use. It’s better to have many small, specific interfaces than a few large, general-purpose ones ² ⁵ ³.
Dependency Inversion Principle (DIP):
High-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions ² ⁵ ³.

Applying SOLID leads to code that is easier to understand, modify, test, and extend as software evolves ¹ ⁵ ³.

1. Single Responsibility Principle (SRP)

The Good: A class handles only one responsibility-separating invoice logic, printing, and saving:

1
class Invoice {
2
  constructor(private amount: number) {}
3
  getTotal() {
4
    return this.amount;
5
  }
6
}
7

8
class InvoicePrinter {
9
  print(invoice: Invoice) {
10
    console.log(`Invoice total: $${invoice.getTotal()}`);
11
  }
12
}
13

14
class InvoiceSaver {
15
  save(invoice: Invoice) {
16
    // Save invoice to database
17
    console.log('Invoice saved.');
18
  }
19
}

How this applies SRP:

The Invoice class has one responsibility: managing invoice data and calculations
The InvoicePrinter class has one responsibility: formatting and printing invoices
The InvoiceSaver class has one responsibility: persisting invoices to storage
Each class has only one reason to change (invoice logic, printing format, or storage mechanism)

The Bad (SRP Violation):

1
class Invoice {
2
  constructor(private amount: number) {}
3

4
  getTotal() {
5
    return this.amount;
6
  }
7

8
  // Violates SRP: Invoice shouldn't handle printing
9
  print() {
10
    console.log(`Invoice total: $${this.getTotal()}`);
11
  }
12

13
  // Violates SRP: Invoice shouldn't handle persistence
14
  save() {
15
    console.log('Invoice saved to database.');
16
    // Database saving logic here
17
  }
18

19
  // Violates SRP: Invoice shouldn't handle email notifications
20
  sendEmail() {
21
    console.log('Invoice email sent.');
22
    // Email sending logic here
23
  }
24
}

This violates SRP because the Invoice class has multiple reasons to change: invoice calculations, printing format, database structure, and email service changes.

2. Open/Closed Principle (OCP)

The Good: Shapes can be extended with new types without modifying existing code:

1
interface Shape {
2
  area(): number;
3
}
4

5
class Rectangle implements Shape {
6
  constructor(private width: number, private height: number) {}
7
  area() {
8
    return this.width * this.height;
9
  }
10
}
11

12
class Circle implements Shape {
13
  constructor(private radius: number) {}
14
  area() {
15
    return Math.PI * this.radius * this.radius;
16
  }
17
}
18

19
class AreaCalculator {
20
  static totalArea(shapes: Shape[]) {
21
    return shapes.reduce((acc, shape) => acc + shape.area(), 0);
22
  }
23
}

How this applies OCP:

The system is open for extension: new shape types can be added by implementing the Shape interface
The system is closed for modification: existing code (AreaCalculator, Rectangle, Circle) doesn’t need to change when adding new shapes
The AreaCalculator works with any shape that implements the interface

The Bad (OCP Violation):

1
enum ShapeType {
2
  Rectangle = 'rectangle',
3
  Circle = 'circle',
4
  Triangle = 'triangle' // Adding this requires modifying AreaCalculator
5
}
6

7
class Shape {
8
  constructor(public type: ShapeType, public dimensions: number[]) {}
9
}
10

11
class AreaCalculator {
12
  static totalArea(shapes: Shape[]) {
13
    return shapes.reduce((acc, shape) => {
14
      // Violates OCP: Adding new shapes requires modifying this method
15
      switch (shape.type) {
16
        case ShapeType.Rectangle:
17
          return acc + (shape.dimensions[0] * shape.dimensions[1]);
18
        case ShapeType.Circle:
19
          return acc + (Math.PI * shape.dimensions[0] * shape.dimensions[0]);
20
        case ShapeType.Triangle:
21
          return acc + (0.5 * shape.dimensions[0] * shape.dimensions[1]);
22
        default:
23
          return acc;
24
      }
25
    }, 0);
26
  }
27
}

This violates OCP because adding a new shape type requires modifying the AreaCalculator class.

3. Liskov Substitution Principle (LSP)

The Good: Subclasses should work as their base type expects:

1
abstract class Bird {
2
  abstract move(): void;
3
}
4

5
class FlyingBird extends Bird {
6
  move() {
7
    console.log('Flying through the air');
8
  }
9

10
  fly() {
11
    console.log('Flapping wings');
12
  }
13
}
14

15
class WalkingBird extends Bird {
16
  move() {
17
    console.log('Walking on the ground');
18
  }
19

20
  walk() {
21
    console.log('Moving legs');
22
  }
23
}
24

25
class Sparrow extends FlyingBird {
26
  move() {
27
    console.log('Sparrow flying');
28
  }
29
}
30

31
class Ostrich extends WalkingBird {
32
  move() {
33
    console.log('Ostrich running');
34
  }
35
}
36

37
function moveBird(bird: Bird) {
38
  bird.move(); // Works for all bird types
39
}

How this applies LSP:

All bird subclasses can be substituted for the base Bird class
The moveBird function works correctly with any bird type
Each subclass maintains the behavioral contract of the base class

The Bad (LSP Violation):

1
class Bird {
2
  fly() {
3
    console.log('Flying');
4
  }
5
}
6

7
class Sparrow extends Bird {
8
  fly() {
9
    console.log('Sparrow flying');
10
  }
11
}
12

13
class Ostrich extends Bird {
14
  fly() {
15
    // Violates LSP: Ostrich can't fly, breaking the expected behavior
16
    throw new Error('Ostrich cannot fly');
17
  }
18
}
19

20
function makeBirdFly(bird: Bird) {
21
  bird.fly(); // Expects all birds to fly
22
}
23

24
const sparrow = new Sparrow();
25
makeBirdFly(sparrow); // Works fine
26

27
const ostrich = new Ostrich();
28
makeBirdFly(ostrich); // Throws error - violates LSP

This violates LSP because Ostrich cannot be substituted for Bird without breaking the program’s functionality.

4. Interface Segregation Principle (ISP)

The Good: Clients depend only on interfaces they use:

1
interface Printer {
2
  print(): void;
3
}
4

5
interface Scanner {
6
  scan(): void;
7
}
8

9
interface Fax {
10
  fax(): void;
11
}
12

13
class MultiFunctionPrinter implements Printer, Scanner, Fax {
14
  print() {
15
    console.log('Printing document');
16
  }
17
  scan() {
18
    console.log('Scanning document');
19
  }
20
  fax() {
21
    console.log('Faxing document');
22
  }
23
}
24

25
class SimplePrinter implements Printer {
26
  print() {
27
    console.log('Printing document');
28
  }
29
}
30

31
class PhotocopierMachine implements Printer, Scanner {
32
  print() {
33
    console.log('Printing document');
34
  }
35
  scan() {
36
    console.log('Scanning document');
37
  }
38
}

How this applies ISP:

Interfaces are small and focused on specific functionality
Clients only implement the interfaces they need
SimplePrinter doesn’t need to implement scanning or faxing functionality
Each interface represents a cohesive set of related methods

The Bad (ISP Violation):

1
interface Machine {
2
  print(): void;
3
  scan(): void;
4
  fax(): void;
5
  photocopy(): void;
6
}
7

8
class MultiFunctionPrinter implements Machine {
9
  print() {
10
    console.log('Printing document');
11
  }
12
  scan() {
13
    console.log('Scanning document');
14
  }
15
  fax() {
16
    console.log('Faxing document');
17
  }
18
  photocopy() {
19
    console.log('Photocopying document');
20
  }
21
}
22

23
class SimplePrinter implements Machine {
24
  print() {
25
    console.log('Printing document');
26
  }
27

28
  // Violates ISP: Forced to implement methods it doesn't use
29
  scan() {
30
    throw new Error('Scan not supported');
31
  }
32

33
  fax() {
34
    throw new Error('Fax not supported');
35
  }
36

37
  photocopy() {
38
    throw new Error('Photocopy not supported');
39
  }
40
}

This violates ISP because SimplePrinter is forced to implement methods it doesn’t support, leading to empty implementations or exceptions.

5. Dependency Inversion Principle (DIP)

The Good: High-level modules depend on abstractions, not concrete classes:

1
interface Database {
2
  save(data: string): void;
3
  find(id: string): string | null;
4
}
5

6
interface Logger {
7
  log(message: string): void;
8
}
9

10
class MySQLDatabase implements Database {
11
  save(data: string) {
12
    console.log(`Saving data to MySQL: ${data}`);
13
  }
14

15
  find(id: string) {
16
    console.log(`Finding data in MySQL with ID: ${id}`);
17
    return "MySQL data";
18
  }
19
}
20

21
class FileLogger implements Logger {
22
  log(message: string) {
23
    console.log(`Logging to file: ${message}`);
24
  }
25
}
26

27
class UserService {
28
  constructor(
29
    private database: Database,  // Depends on abstraction
30
    private logger: Logger       // Depends on abstraction
31
  ) {}
32

33
  createUser(userData: string) {
34
    this.database.save(userData);
35
    this.logger.log('User created successfully');
36
  }
37
}
38

39
// Dependency injection
40
const database = new MySQLDatabase();
41
const logger = new FileLogger();
42
const userService = new UserService(database, logger);

How this applies DIP:

UserService (high-level module) depends on Database and Logger interfaces (abstractions)
It doesn’t depend on concrete implementations like MySQLDatabase or FileLogger
Dependencies are injected, making the system flexible and testable
New database or logging implementations can be swapped without changing UserService

The Bad (DIP Violation):

1
class MySQLDatabase {
2
  save(data: string) {
3
    console.log(`Saving data to MySQL: ${data}`);
4
  }
5

6
  find(id: string) {
7
    console.log(`Finding data in MySQL with ID: ${id}`);
8
    return "MySQL data";
9
  }
10
}
11

12
class FileLogger {
13
  log(message: string) {
14
    console.log(`Logging to file: ${message}`);
15
  }
16
}
17

18
class UserService {
19
  private database: MySQLDatabase;  // Violates DIP: depends on concrete class
20
  private logger: FileLogger;       // Violates DIP: depends on concrete class
21

22
  constructor() {
23
    // Violates DIP: creates dependencies internally
24
    this.database = new MySQLDatabase();
25
    this.logger = new FileLogger();
26
  }
27

28
  createUser(userData: string) {
29
    this.database.save(userData);
30
    this.logger.log('User created successfully');
31
  }
32
}
33

34
// Tightly coupled - hard to test and inflexible
35
const userService = new UserService();

This violates DIP because:

UserService depends directly on concrete classes (MySQLDatabase, FileLogger)
It creates its own dependencies, making it tightly coupled
It’s difficult to test (can’t mock dependencies)
Changing database or logging implementation requires modifying UserService

← Decision Tree: DyanamoDB vs Aurora PostgreSQL

A Tale of Software Rot →