1. Overview

HI friends, in this tutorial, I am going to talk about SOLID principles in JAVA.

First of all, SOLID is an acronym for 5 principles in software development. They are :

• Single Responsibility Principle
• Open Closed Principle
• Liskov Substitution Principle
• Interface Segregation Principle
• Dependency Inversion Principle

2. Why we need SOLID Principles

I believe, SOLID Principles are the corner stone of Object Oriented Programming. Cause of that, it is one of the most questioned topic in the interviews. The reason is, it prevents the project to become mass. Or, let’s say, becoming spaghetti over time.

In addition to that, these principles are highly important and demanding in the market. So if we are good with these principles and implementing them in our code, then it makes us one step ahead than others.

This is also beneficial for setting the standards in a project. If we follow the SOLID Principles in our project, the new joiners will understand it easily, and eventually it will be easier to maintain the project.

3. Single Responsibility Principle – SOLID Principles

Let’s hear the description of Single Responsibility Principle from the best :

A module should be responsible to one, and only one, actor.  – Robert Cecil Martin (Uncle Bob) – Clean Architecture

By far, the easiest principle in the solid principles is the single responsibility. Just keep in mind that one class/service/method should have one responsibility. It can be a general responsibility, tho. Think like you have a service which is responsible for transactions of accounts. So that service shouldn’t handle user registration operations.

I’ve shared greater explanation and a good coding example in java at this blog post : Single Responsibility in JAVA //Will be added.

4. Open Closed Principle – SOLID Principles

The second principle is Open Closed Principle. The name stands for the explanation : Open for extension, closed for modification. That means, your code should be open for any new coming updates, but those updates should obey the existing class rules.

Let’s give it an example : Think like, we have an app that tracks your sleep schedule. Also in that app, we have a web page that shows the graph of your sleeping routine and other stuff related with it. That was our MVP. So after some time, our users keep asking us to create a PDF file out of those data and send it to their email address. Now, since we have the data, and we have the web page design to show it, we shouldn’t change much code to achieve that request. Here you see :

– Open for extension : Now we’ve to write some methods and some additional classes to do the trick for implementing PDF generation. Also, we will add a service to send PDF to users email addresses.

– Close for modification : We don’t have to re-invent the wheel. We shouldn’t write the service methods from scratch. Also, we shouldn’t update the existing logic. There should be a new class with the extension / implementation of existing code base.

I’ve shared greater explanation and a good coding example in java at this blog post : Open Close in JAVA //Will be added.

5. Liskov Substitution Principle – SOLID Principles

The best thing to describe this principle is a MEME :

The brief description of this principle is, let’s say you have a class A and class B extends the class A. In your code, the changing the usages of class A to class B shouldn’t trigger any problem. Inherited classes should obey their parent’s rules.

A common example for this principle is the square-rectangle problem. A square is a rectangle, but if we try to use the square class instead of its parent rectangle class, we might end up with a wrong calculation of the area and circumference.

I’ve shared greater explanation and a good coding example in java at this blog post : Liskov Substitution in JAVA //Will be added.

6. Interface Segregation Principle

Interface segregation is another easy to understand principle. The segregation means isolation, right? So think like, we have to segregate interfaces in a way that it is used only when it is necessary.

Let’s share an example to understand it better. Let’s say we have a marketplace application consists of buyers and sellers. We have defined a UserInterface that has varied of methods, along with buy() and sell() methods. Don’t overthink on it. Just focus on the idea. When we are going to create a class for seller, we will implement the UserInterface, and we have to override buy() method too. That is a problem. Probably, our buy() method will look like this :

public void buy() {
// WHUT? Not needed / NA.
}

I’ve shared greater explanation and a good coding example in java at this blog post : Interface Segregation Principle in JAVA //Will be added.

7. Dependency Inversion Principle

Dependency inversion principle is basically your code should not be dependent on the concrete classes. Instead, it should be dependent on that concrete classes interface or abstract class. Why? Because, in the future, we might want to use the same functionality with a different concrete operation. So, it will be just a single line of code to implement new functionality to your project in the future. Let’s say, this principle lets us write future-proof code.

An example? Here it is. Think that we have a depot control application that accepts sales from retail shops. It will work well till we decide to accept sales from our new ecommerce website. To prevent code changes that might happen in the future, we should be dependent on selling operation instead of retail shop.

You can find greater explanation and a good coding example in java at this blog post : Dependency Inversion Principle in JAVA //Will be added.

8. Conclusion

In this blog post, I’ve tried to explain about SOLID principles. The thing is, there are a lot of different pages that tries to explain these principles in the same way. This is why I try to do more examples on principles and added separate posts per each. If you have any suggestions, please don’t hesitate to contact me.