Make Use of SOLID Coding Principles

We all know what are the pros and cons of Object Oriented Programming, but what about writing better codes? What about making it more flexible and easier to read? Well, here are some tips on SOLID Design Pattern and the easy thumb rules to keep in mind while coding.

I am personally focused on how to use SOLID principles with some practical approaches, rather than understanding the huge theoretical knowledge. So, below I have tried to explain the approaches as simplified as possible. I am a strong believer of starting with something and then improvising on my own.

Single Responsibility Principle :

The first principle of SOLID Design Patterns is as follows –

A class should have a single responsibility and one reason to change.

Anti-Pattern of Single Responsibility Principle

What should be done ?

Always think of the logic and the business rules which are only applicable for that class.

“Gather together the things that change for the same reasons. Separate those things that change for different reasons.”- Robert C. Martin

Open-Close Principle :

The second principle of SOLID Design Pattern is as follows –

A class should be open for extension and closed for modification.

Problems when your class is not extensible

What should be done ?

Write your codes in a way so that, if someone wants to add a new functionality to the class in future, he or she won’t have to touch your existing code.

Liskov Substitution Principles :

The third principle of SOLID Design Pattern is as follows –

Any object of some class in can be replaced by an object of a child class.

What should be done ?

If you have two classes, class A and class B, where B is a subclass of A, all the methods which are mentioned in class A should have implementation in class B.

Interface Segregation Principle :

The fourth principle of SOLID Design Pattern is as follows –

Clients should not be forced to depend on methods that they do not use.

Problems : Client will expect it to work, but the method was not implemented

What should be done ?

Lets’ assume, I have an interface having two methods x() and y(). Two of my classes A and B implements the interface, but Class A has only the functionality of x(), where Class B has both of the functionalities x() and y(). The easiest way to solve this is, override y() in class A, and implement nothing in it… which will directly lead us to the situation shown in the gif above.

The Pattern is to create two interfaces. One will have the common functionalities and the second interface will have the extra functions (i.e. y() from the above example) and will extend the first interface. Now, when we will implement class A, we will implement the first interface, but for class B, we will implement the second interface.

Data Inversion Principle :

The fifth principle of SOLID Design Pattern is as follows –

High level modules should not depend upon low level modules. Both should depend upon abstractions.

What should be done ?

We should not extend concrete classes, we should always depend on abstractions like abstract classes or interfaces.

Please check out my other posts on Technology.

Parijat Mukherjee

Hi There !!! I am a Software Engineer and I am always in a process of learning something new. I love the works that are outside my comfort zone. Rather than focusing on a particular programming language, I try to focus on the design patterns and technologies because I believe, if someone understands the "What" and the "Why" part of a problem and the technology or tool, then the "How" part can be easily done by any of the programming language available in the market.

Comments are closed.

Recent Posts

Spring Security Architecture – Authentication

The Spring Security project is perhaps the biggest and one of the best projects so far by Spring. When I…

2 months ago

Free Birthday and Anniversary Mail Sender Software

Open Source Application to send Birthday and Anniversary greetings to the employees

3 months ago

How to Dockerize Spring Boot Applications

Article to demonstrate how to dockerize a spring boot application with all the required maven dependency plugins and Dockerfile.

4 months ago

Create a Spring Boot 2 Application & Register it in Eureka

Spring boot tutorial and a eureka client example including eureka client properties to guide the microservice beginners.

5 months ago

Create Eureka Server Using Spring Cloud

Quick beginners guide to Eureka Server using Spring Cloud with all the necessary eureka server dependency maven dependencies and eureka…

5 months ago

How to create MariaDB Galera Cluster in CentOS 6.x

Galera cluster tutorial and overview for the beginners followed by galera cluster setup centos 6 and galera cluster configuration.

2 years ago