What is SOLID and how does it help us write better code?

In software engineering, SOLID is one of the most popular sets of design principles in object-oriented software development.

The SOLID principles were introduced by Robert C. Martin in his 2000 paper?“Design Principles and Design Patterns.”?These concepts were later built upon by Michael Feathers, who introduced us to the SOLID acronym. And in the last 21 years, these five principles have revolutionized the world of object-oriented programming, changing the way that we write software.

These principles establish practices that lend to developing software with considerations for maintaining and extending as the project grows. Adopting these practices can also contribute to avoiding code smells, refactoring code, and Agile or Adaptive software development.

Now, let’s begin!

SOLID stands for:

S - Single-responsibility Principle (SRP)

O - Open-closed Principle (OCP)

L - Liskov Substitution Principle (LSP)

I - Interface Segregation Principle (ISP)

D - Dependency Inversion Principle (DIP)

In this article, you will be introduced to each principle individually to understand how SOLID can help make you a better developer.

1. Single-Responsibility Principle

Single-responsibility Principle (SRP) states:

A class should have one and only one reason to change, meaning that a class should have only one job.

If a Class has many responsibilities, it increases the possibility of bugs because making changes to one of its responsibilities, could affect the other ones without you knowing.

Let's see a few of its benefits:

1. Testing?– A class with one responsibility will have far fewer test cases.
2. Lower coupling?– Less functionality in a single class will have fewer dependencies.
3. Organization?– Smaller, well-organized classes are easier to search than monolithic ones.

Goal

This principle aims to separate behaviors so that if bugs arise as a result of your change, it won’t affect other unrelated behaviors.

2. Open-Closed Principle

The Open-Closed Principle (OCP) states:

Objects or entities should be open for extension but closed for modification.

This means that a class should be extendable without modifying the class itself.

Changing the current behavior of a Class will affect all the systems using that Class.

If you want the Class to perform more functions, the ideal approach is to add to the functions that already exist NOT change them.

Goal

This principle aims to extend a Class’s behavior without changing the existing behavior of that Class. This is to avoid causing bugs wherever the Class is being used.

3. Liskov Substitution Principle

Liskov Substitution Principle states:

Let q(x) be a property provable about objects of x of type T. Then q(y) should be provable for objects y of type S where S is a subtype of T.

The Liskov Substitution principle was introduced by?Barbara Liskov?in her conference keynote “Data abstraction” in 1987. A few years later, she published a paper with Jeanette Wing in which they defined the principle as:

If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program.

This means that every subclass or derived class should be substitutable for their base or parent class.

When a?child?Class cannot perform the same actions as its?parent?Class, this can cause bugs.

If you have a Class and create another Class from it, it becomes a?parent?and the new Class becomes a?child.?The?child?Class should be able to do everything the?parent?Class can do. This process is called?Inheritance.

The?child?Class should be able to process the same requests and deliver the same result as the?parent?Class or it could deliver a result that is of the same type.

The picture shows that the?parent?Class delivers Coffee(it could be any type of coffee). It is acceptable for the?child?Class to deliver Cappucino because it is a specific type of Coffee, but it is NOT acceptable to deliver Water.

If the?child?Class doesn’t meet these requirements, it means the?child?Class is changed completely and violates this principle.

If class?A?is a subtype of class?B, we should be able to replace?B?with?A?without disrupting the behavior of our program.

Goal

This principle aims to enforce consistency so that the parent Class or its child Class can be used in the same way without any errors.

4. Interface Segregation Principle

The Interface Segregation Principle was defined by Robert C. Martin while consulting for Xerox to help them build the software for their new printer systems. He defined it as:

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

When a Class is required to perform actions that are not useful, it is wasteful and may produce unexpected bugs if the Class does not have the ability to perform those actions.

A Class should perform only actions that are needed to fulfill its role. Any other action should be removed completely or moved somewhere else if it might be used by another Class in the future.

Goal

This principle aims at splitting a set of actions into smaller sets so that a Class executes ONLY the set of actions it requires.

5. Dependency Inversion Principle

The dependency inversion principle states:

Entities must depend on abstractions, not on concretions. It states that the high-level module must not depend on the low-level module, but they should depend on abstractions.

This principle allows for decoupling.

- High-level modules should not depend on low-level modules. Both should depend on the abstraction.

- Abstractions should not depend on details. Details should depend on abstractions.

High-level Module(or Class): Class that executes an action with a tool.

Low-level Module (or Class): The tool that is needed to execute the action

Abstraction: Represents an interface that connects the two Classes.

Details: How the tool works

This principle says a Class should not be fused with the tool it uses to execute an action. Rather, it should be fused to the interface that will allow the tool to connect to the Class.

It also says that both the Class and the interface should not know how the tool works. However, the tool needs to meet the specification of the interface.

Goal

This principle aims at reducing the dependency of a high-level Class on the low-level Class by introducing an interface.

_________________________________________________________________________

Thank you so much for reading. I hope you have a better idea about this topic and you had as much fun reading this as I did writing it.