What is SOLID? SOLID Principles with Examples

The theory of SOLID principles was first introduced in the article titled Design Principles and Design Patterns (Design Principles and Design Patterns), published in 2000 by Robert Martin, also known as "Uncle Bob".

In object-oriented computer programming, SOLID is an acronym formed from the initials of five design principles aimed at making software designs more understandable, flexible, and maintainable. 

Although they refer to object-oriented design, SOLID principles can form a fundamental philosophy for methodologies like agile development or adaptive software development. 

These principles help software developers design robust, testable, extensible, and maintainable object-oriented software programs.

SOLID stands for:

1. S - Single Responsibility Principle
2. O - Open-Closed Principle 
3. L - Liskov Substitution Principle
4. I - Interface Segregation Principle
5. D - Dependency Inversion Principle

Each of these five design principles addresses a specific problem that can arise during the development of software systems.

Now that we've learned what SOLID is, let's take a closer look at these principles. 👀

SOLID Design Principles in Software Engineering

In the previous section, we mentioned that the SOLID design principles is an acronym for five principles: Single Responsibility Principle, Open-Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle.

Adopting these principles can help us avoid refactoring code and produce Agile software. 

Single Responsibility Principle (SRP)

Simply put, the single responsibility in the SOLID design principle states that a class, module, or function should have only one job. In other words, it says that each class should have only one reason to change. 

If there is more than one reason to change a class, then the class can be considered to have multiple responsibilities. The methods within the class may be overly interrelated with methods in other classes. In that case, the class can be considered highly coupled. In this situation, it can be said that coupling leads to rigid designs and can result in undesired outcomes when making any requirements or changes. 

If a class contains logic to perform more than one job, it won't be easy to debug and maintain as the codebase grows. New developers may have difficulty reading and understanding the code.

If we ensure that each class performs only one job, not only will it be easier to maintain and debug the code, but the code will also become reusable because each core function is performed by a single class. 

To illustrate this with an example 👇;

The code above violates the single responsibility principle because the class responsible for printing the animal's name also shows the sound it makes and its feeding method.

So, you might be wondering what to do in this case. To fix this, you need to create a separate class for the sound and feeding methods:

In this way, each class does only one thing:

• the first prints the animal's name
• the second prints the type of sound it makes
• the third prints its feeding method.

This requires writing more code but provides better readability and maintainability. 

Open-Closed Principle

The open-closed principle in SOLID design principles states that software entities should be open for extension but closed for modification.

This principle may seem contradictory within itself, but you can understand it better in code. 

Software components should be open for extension and closed for modification. It means that you should be able to extend the functionality of a class, module, or function by adding more code without changing existing code.

The context of a software piece can extend its behavior without altering the source code, or a class can be easily extended without changing the class behavior. When requirements change, the behavior of such modules can be extended by adding new code rather than modifying already working old code. 

Liskov Substitution Principle

The Liskov substitution principle is one of the most important principles to follow in object-oriented programming (OOP). It was introduced by computer scientist Barbara Liskov in a paper co-authored with Jeannette Wing in 1987.

This principle tells us that if a type is derived from a base type, the derived type must support substitutability for the base type. Simply put, it states that subclasses should be substitutable for their base or parent classes. In other words, a child class should be able to replace its parent class. 

Let's look at how the following code violates the Liskov substitution principle:

The Bird class does not implement its own specific makeSound method from the Animal superclass. Instead, it uses a general makeAnimalSound method, which violates the Liskov substitution principle.

Interface Segregation Principle

The interface segregation in SOLID design principles states that larger interfaces should be divided into smaller ones. By doing so, we can ensure that classes only have to deal with the methods that are relevant to them. 

This can make the codebase easier to maintain. In other words, multiple client-specific interfaces are better than one general interface. 

Dependency Inversion Principle

Dependency inversion is about separating software modules from each other. Thus, if class A changes, class B doesn't need to care or be aware of the changes.

This principle states that high-level modules should not depend on low-level modules. Both should depend on abstractions. Additionally, abstractions should not depend on details; details should depend on abstractions.

In simpler terms, this means that instead of writing code that relies on specific details about how low-level code works, you should write code that relies on more general abstractions that can be implemented in different ways.

Why Is SOLID Important?

You've already seen why SOLID principles are important in Object-Oriented Programming (OOP). But to list them 👇;

1. Makes Changes Easier: Think of a big puzzle. Each piece fits into a specific place. If a piece breaks, you only need to replace that piece. Similarly, when you follow the SRP (Single Responsibility Principle), each class has a specific task. This helps you know exactly where to look when you need to make a change. The OCP (Open-Closed Principle) allows you to add new features without changing existing code, which helps keep your code stable.
2. Enables Code Reuse (OCP and ISP): Think of LEGO bricks. You can build different structures using the same pieces. Similarly, with OCP (Open-Closed Principle), you can create new features by extending existing classes. This reusability saves time and effort. The ISP (Interface Segregation Principle) ensures that classes are only dependent on what they need, making them more flexible and reusable.
3. Makes Testing Easier (DIP): Think of a car with interchangeable parts. If a part breaks, you can replace it without rebuilding the whole car. Similarly, when you apply the DIP (Dependency Inversion Principle), your code depends on abstractions, making it much easier to test. You can swap out components for testing purposes without affecting the rest of the code. 
4. Works in Harmony (DIP): Think of a doctor working in different departments of a hospital. Each doctor knows exactly what they're responsible for. Similarly, when the DIP principle is followed, developers can work on different parts of a project simultaneously. This reduces misunderstandings and facilitates smoother collaboration.

Are SOLID Principles Still Valid?

Since Robert Martin first developed the SOLID software design principles, technology and the software industry have undergone significant changes. Yet, their core ideas remain globally valid today.

The SOLID principle aims to reduce dependencies and increase maintainability. During software development, extra time and effort must be spent for each principle. Thus, code complexity can be reduced, and the maintainability of the code can be increased. 

They provide flexible design, low coupling, and greater ease of maintenance. The code becomes more robust, stable, and better understandable. 

At first, SOLID design principles may seem overwhelming, but once you get into the habit of working with them regularly, the complexity in your code will decrease, and your work will become easier. :)