SOLID Principles: Basic building block of the software system

SOLID Principles: Basic building block of the software system

Reading Time: 4 minutes

“Good software system begins with clean code” and by “clean code”, I mean it is code that is easy to understand and easy to change.
This is the point where there is a need to know about SOLID Principles which helps us in writing the clean code as the code is like humour. “When you have to explain it, it’s bad.” The SOLID PRINCIPLES tell us how to arrange our methods/functions and how those classes should be interrelated to each other and the data structures into classes.
The goal of the principles is the creation of software structures that is:
• Easy to modify,
• Easy to understand.

This blog is all about the introduction of SOLID principles.

SOLID Principles are as follow:-

S – Single responsibility principle
O – Open closed principle
L – Liskov substitution principle
I – Interface segregation principle
D – Dependency Inversion principle

Single Responsibility Principle(SRP)

It is one of all the SOLID principles that we have in the programming world. According to Rober C. Martin, SRP ,  “a class or modules should have one, and only one, a reason to change” or we can say that “There should be no more than one reason to modify a class or a module.”

Example:- A  EmployeeReviewer class is only responsible for counting the appraisal score of an employee according to his/her performance criteria fixed by the company. This class should only change if the criteria fixed by the company will change.

Open Closed Principle(OCP)

OCP states that “A software artifact should be open for extension but closed for modification“. It means software structure is designed like that with every new release we added the code for new functionality instead of modifying the previous one. In other words, the behaviour of a software artifact ought to be extendable, without having to modify that artifact.

Example:- Software development is similar to build the multistore building. So the design should be like that if we are going to add a new feature then this can be easily achieved by adding some new functions/methods or classes instead of modifying the previous one. Like we are planning to make the house, we already build a room in it, then to make a kitchen if we have to modify the already created rooms for it, then obviously the design for building the house is not correct. Same rules apply for designing the software system.

Liskov Substitution Principle(LSP)

LSP tells us that “Derived classes must be substitutable for their base classes.” What exactly Barbara Liskov wrote “What is wanted here is something like the following substitution property: If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T”. In very easy words, we can also say that “objects in a program should be replaceable with instances of their subtypes without altering the correctness of the program“.

Example:- You have an instance of the class Bike which our program uses to perform a drive action. This instance could be replaced by an instance of the class Honda, if Honda is a subclass of Bike.

Interface Segregation Principle(ISP)

ISP states “Many client specific interfaces are better than one general purpose interface“. The soul of the principle is quite simple. If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each client and multiply inherit them into the class.

Example:- Suppose we have a company management system with different type of roles like admin, hr, employee etc. Instead of a class which can perform all the actions for all these types, we would create separate classes for each type which implement their specific actions according to our use case.

Dependency Inversion Principle(DIP)

DIP states “Depend upon Abstractions. Do not depend upon concretions“. The DIP states the primary mechanism. Dependency Inversion is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes. This structure starts at the top and points down towards details. High-level modules depend upon lower level modules, which depend upon yet lower level modules, etc.

Example:- Imagine we have a class Distributer which is able to share a blog post on different platforms like twitter, facebook etc. According to the Interface Segregation Principle, the distributer uses a composition of several instances, like a TwitterShareAction and a FacebookShareAction. Now the goal of the Dependency Inversion Principle is to not depend on concrete methods of the share action classes, like sharePostOnTwitter and sharePostOnFacebook. Instead, the Distributer class would define an interface called Sharing which is implemented by TwitterShareAction and FacebookShareAction. It declares the abstract method sharePost. The Distributer class doesn’t have to know the details of the concrete share actions. It just calls the sharePost method.

Advantages of following SOLID principles

• Code complexity is reduced by being more explicit and straightforward,
• Readability is greatly improved,
• Coupling is generally reduced,
• Your code has a better chance of cleanly evolving.

References:-

Clean Architecture by Robert c. Martin