All you need to know about SOLID Principles

Table of contents

Reading Time: 3 minutes

In this blog post, we will discuss about SOLID principles in Scala which are the 5 most recommended design principles.

What are SOLID Principles ?

The abbreviation SOLID stands for a collection of principles that, when combined, make code more adaptable to change. SOLID principles assist us in making our software more readable, understandable, flexible. They serve as the foundation for developing object-oriented applications that are robust, extensible, and maintainable.

The acronym SOLID Principle refers to a set of five principles, namely

S – Single Responsibility Principle
O – Open/Closed Principle
L – Liskov’s Substitution Principle
I – Interface Segregation Principle
D – Dependency Inversion Principle

Let’s take a closer look at the principles.

1) Single Responsibility Principle

Single responsibility principle mainly stands for

“One class should have one and only one responsibility”.

That means a single duty should be assigned to a class, and there should be only one cause to change or modify it. We must break into multiple classes when there is another cause to alter classes.

Consider the development of software. When the task is divided into different members who do different things, such as front-end designers who design, testers who test, similarly backend developers who handle backend development. Therefore, we can say that everyone has a single job or responsibility.

2) Open/Closed Principle

Open closed principle mainly stands for

“Software entities should be open for extension, but closed for modification”

It means that the entity which we create should be extensible. We can create a new feature or behavior without breaking the existing code by applying this principle.

The application classes should be structured in such a way that if other developers wish to change the flow of control under a given scenario in the application, then they can do that by extending the classes and overriding a few functions. We should reconsider refactoring the class if other developers are unable to write the desired behaviour owing to the constraints imposed by the class.

3) Liskov’s Substitution Principle

Liskov’s Substitution principle mainly stands for

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

This generally requires that the objects of the subclasses behave similarly to the objects of the superclass. This is important when we implement polymorphic behaviour via inheritance.

A four-sided rectangle is a classic example of this principle. The height and width of a rectangle can both be any value. A square is a rectangle with equal width and height. As a result, we can say that we can extend the properties of the rectangle class into the square class. To do so, you must swap the child (square) class with the parent (rectangle) class to fit the definition of a square with four equal sides, but a derived class does not affect the behaviour of the parent class, so doing so violates the Liskov Substitution Principle.

4) Interface Segregation Principle

Interface Segregation principle mainly stands for

“Clients should not be forced to implement unnecessary methods which they will not use”

This is the first principle in SOLID that applies to interfaces rather than classes, and it is similar to the single responsibility principle.

The main goal here is to avoid fat interfaces and prioritise many small client-specific interfaces. You should prefer multiple client interfaces to a single general interface, and each interface should be responsible for a specific task. Thus, many client-specific interfaces outperform a single general-purpose interface.

5) Dependency Inversion Principle

Dependency Inversion principle mainly stands for

“Depend on abstractions, not on concretions”

Dependency Inversion is an excellent method for reducing tight coupling in our software. We should design our software in such a way that different modules can be separated from one another while still being linked together by an abstract layer.

If a high-level module or class is more dependent on low-level modules or classes, your code will have tight coupling, and if you make a change in one class, it may break another. So always try to make classes as loosely coupled as possible through abstraction. The main goal of this principle is to decouple the dependencies so that if class A changes, class B does not need to care or be aware of the changes.

Conclusion

Thank you guys for making it to the end of the blog I hope you gained some knowledge about solid principles as well as their significance. You can also check other blogs here.