S.O.L.I.D. Principles Around You

20 June, 2017

In this article, I want to briefly go through SOLID principles (the acronym that stands for five basic principles of object-oriented programming and design) supplying each of them with real-world visual examples to make those principles more understandable, readable and memorizable.

If you want to see code examples instead you may take a look at variety of tree data structure implementations in JavaScript like Binary Search Tree, AVL Tree, Red-Black Tree, Segment Tree or Fenwick Tree.

You may also check the interactive SOLID Sketches

So let’s move on!

S — Single Responsibility Principle

a.k.a SRP

A class should have only a single responsibility. Only one potential change in the software’s specification should be able to affect the specification of the class.

Single Responsibility Principle

O — Open/Closed Principle

a.k.a OCP

Software entities should be open for EXTENSION, but closed for MODIFICATION. Allow behavior to be extended without modifying the source code.

Open/Closed Principle

L — Liskov Substitution Principle

a.k.a. LSP

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

Liskov Substitution Principle

I — Interface Segregation Principle

a.k.a. ISP

Many client-specific interfaces are better than one general-purpose interface. No client should be forced to depend on methods it does not use.

Interface Segregation Principle

D — Dependency Inversion Principle

a.k.a. DIP

One should depend upon abstractions, not concretions.

  • 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.
Dependency Inversion Principle

The plug doesn’t care which type of wire it uses, it just needs wires that conduct electricity.

I hope these illustrations have been useful for you :)

Subscribe to the Newsletter

Get my latest posts and project updates by email