Backend development can get messy. But as a backend developer, it’s your job to ensure that the code you write is understandable and maintainable in the future. All backend developers have suffered the pleasure of trying to unpick legacy code written by a previous developer.

This brings us to the SOLID Principles. 5 simple rules of object-oriented design to structure code in an extensible and readable way to help you and your project.

The 5 Solid Principles are:

S – Single responsibility
O – Open/closed
L – Liskov substitution
I – Interface segregation
D – Dependency inversion

OK, I know what you’re thinking, ‘You said simple, they don’t sound simple!’, but I promise they are. Let’s break them down 1 by 1, and understand them.

1. Single Responsibility Principle

A class should only have one job, only a single reason to change.

So for example, let’s take a simple class of a ‘Product’

Now, if we want to add a method for formatting that description for different views, perhaps one would need a set length for example. Your first instinct would be to add a method to the class, but this would violate the Single Responsibility Principle, the Product’s class’s job, in this case, is to store and access the Product, it shouldn’t be concerned about the different ways you would like to represent the description. So instead we should create a separate class that would take the responsibility of outputting the description in the different ways we want.

The advantage of using this kind of approach, is that now if in future you would need to add a different ‘format’ you aren’t cluttering the Product class with logic and information that it doesn’t need to be interested in, you would simply add a new method to the ProductPrinter class. 

2. Open Closed Principle

The idea behind Open Closed is, Open to Extension Closed to Modification. The hope here is that you will refrain from modifying existing code that may lead to bugs and regressions, and instead extend the code going forward.

So let’s go back to our Product Class, but this time we want to add some unique properties that will only be used for a subset of Products, maybe we’re adding Perishable items and we would like to add a ‘best before date’. Instead of adding this to the main ‘Products’ Class where it would only be used a handful of times, we instead extend the Class to create a ‘PerishableProducts’ class. 

3. Liskov Substitution Principle

This is probably the most complex Principle in SOLID, the basic idea behind it is to ensure that when you are designing your classes you ensure that the outputs of the classes you create are interchangeable.

Essentially what you are trying to enforce here is the logic that you don’t create methods or properties of a class that will not be used or may not be applicable to an extension of that class. 

Here’s a good example that explains it quite well:

In this example, there’s a simple class that defines ‘Bird’ and birds can fly, no? But what happens when we need to create a ‘Chicken’ Class that extends this base class? Chickens are birds, but they cannot fly.

Here’s the solution that adhered to the Liskov Principle:

4. Interface Segregation Principle

The basic idea of Interface Segregation is quite simple: Break interfaces down into smaller ones, ensuring that a class shouldn’t have to implement methods it doesn’t need or use. So here’s an example of a Product Interface:

This all seems fine, but what happens when you add digital products to your store in the future? They don’t have ‘stock’, but using this interface would mean you’d need to implement a ‘stockCheck’ method.

Instead it would be better to create a new interface that doesn’t have a ‘checkstock’ method. 

5. Dependency Inversion Principle 

This principle is designed to ensure that dependencies are tied in using abstraction, let’s show an example to make this easier to read. 

Here’s an example of a stock check report that runs, which is reliant on a database connection: 

The problem with this relationship is that in the future if the ‘DatabaseConnection’ Class was changed, you’d also need to check the ‘StockReport’ Class to make sure they are still compatible, this may be forgotten and cause bugs / regressions.

To rectify this we would implement an interface:

And Modify the example as below: 

This allows the StockReport to not care about what database connection we’re using, as long as it implements the DBConnectionInterface, it will work as expected.

Final thoughts

The solid principles are a really powerful way to help you on your journey of development. To assist you in developing clean extensible code.

Thanks for reading!