Ever heard about SOLID Principles?

As a Java Developer who spends his whole life on objects and classes would have definitely heard or implemented SOLID principles. This is not just the case of a Java built application but any application built using an OOPs supporting language like .Net, python etc.

This post is for those people who are new or confused on what SOLID means w.r.t Object Oriented language and the application built using it.

In a nutshell, SOLID is a collection of independent yet interconnected principles used alone or together while developing an enterprise application with OOPs. The expansion is :-

Let's dive into each one of them in a more detailed level.

Single Responsibility Principle

This states that a module, or a class or a method should have only one responsibility.

This statement is true and can be applicable for even in a microservice architecture.

What does this mean is that if your are developing a module or a class or a method it should not be bombarded with lots of operations that makes the code difficult to read, maintain and later bringing more dependency or coupling.

For example, say you have a bill generating module, the name itself says that it should generate a bill and it should not be used to perform any other operation like purchasing or payment. Same goes for a class or method.

Open/Closed Principle

This states that software entities should be open for extension but closed for modification

This means that if you have developed a module or a class or a method, it should easily be consumed by other developers and if you want to make any modification say adding additional feature, it should not impact the existing ones.

The best example is the APIs. Developers consume APIs created by others and use it in the way they want.

Another example is interface. If you have created an interface and there are classes who implement that interface, tomorrow if you want a new feature, then you can easily create a new class and implement this interface without causing problems for classes who are already built and running.

Liskov's Substitution Principle

This states that the derived or child class must be in a position to replace their parent or base class if needed

This immediately brings inheritance concept in mind. Yes, it's true we are talking about inheritance here. When you have objects of base class defined in your application, if there is a need to change the object from parent to child, then it should not cause a hard time to make necessary changes.

Interface Segregation Principle

This states that client or consumer should not be forced to implement all the methods and must be flexible to choose the ones that they require

This means that if you have an interface and lots of classes that implements it, tomorrow when a new class comes and implements, it becomes difficult and a hard restriction comes to override all the methods in that interface.

Instead of making a generic interface with lots of method signature, split the interface to smaller consumable ones.

Dependency Inversion Principle

This states that abstraction should not depend on details, instead details should depend on abstraction

This means that instead of concrete classes depending on each other, if we bring interface or abstract class in between the tight dependency can be avoided. The code becomes flexible enough that if a new class or feature comes in, it can be easily integrated.