Software Design -Introduction to SOLID Principles- Java. Think about this during your java or any codecode.

The story will tell you about the design principle you should consider during your coding. The example will cover java.

Why you should be using solid principles? how you can connect these with your controller, handler, action, service, repository class in java.

Single Responsibility Principle

A class should have one, and only one, reason to change.

One class should only serve one purpose, this does not imply that each class should have only one method but they should all relate directly to the responsibility of the class.

All the methods and properties should all work towards the same goal. When a class serves multiple purposes or responsibilities then it should be made into a new class.

This Class Does Too Much

Instead of one big blob of code, you should follow the Single Responsibility Principle to divide the entire OrderProcessingModule class into a subsystem of related classes, with each class fulfilling its own specialized responsibility. For example, you might put all of the data access functions into a new class called OrderDataService and the order business logic in a different class.

The point of the Single Responsibility Principle isn’t just to write smaller classes and methods. The point is that each class should implement a cohesive set of related functions.

An easy way to follow the Single Responsibility Principle is to constantly ask yourself whether every method and operation of a class is directly related to the name of that class. If you find some methods that do not fit with the name of the class, you should consider moving those methods to another class.

Open-closed Principle

Entities should be open for extension, but closed for modification.

Software entities (classes, modules, functions, etc.) be extendable without actually changing the contents of the class you’re extending.

If we could follow this principle strongly enough, it is possible to then modify the behavior of our code without ever touching a piece of original code.

For example, consider this class:

We want to iterate through a list of dishes and return their cuisine.

The function getCuisines() does not meet the open-closed principle because it cannot be closed against new kind of dishes.

If we add a new dish say Croissant, we need to change the function and add the new code like this.

If you observe, for every new dish, a new logic is added to the getCuisines() function. As per the open-closed principle, the function should be open for extension, not modification.

Here is how we can make the codebase meets the standard to OCP.

This way we do not need to modify the code whenever a new dish is required to add. We can just create a class and extends it with the base class.

Liskov Substitution Principle

The principle revolves around parent and child class objects. By definition is below.

Substitutability is a principle in object-oriented programming stating that, in a computer program, if S is a subtype of T, then objects of type T may be replaced with objects of type S

In simple the above could be defined as below.

  • If we have a class T and have a property of method x(eg circle). If we create an object t from class T we could perform the operation on x with t.
  • If we have a class S that extends T, then object s from S should be able to perform the method x. That is the main s IS-A t.

Bad example

The duck can fly because it is a bird, but what about this:

Ostrich is a bird, but it can’t fly, Ostrich class is a subtype of class Bird, but it shouldn’t be able to use the fly method, which means we are breaking the LSP principle.

Good example

Interface Segregation Principle

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

Assume we have created a simple Set interface as below.

Create a class as below

Create another class as below.

Do you see the problem, even though you do not require ceiling and floor method in HashSet, we have to implement them.
The correct solution for above problem will be:
Create another interface called NavigableSet which will have ceiling and floor method.

public interface NavigableSet<E> {

E ceiling(E e);

E floor(E e);


Remember keep it simple and don’t repeat yourself and you will find that you are already using this principle without knowing.

NOTES: The Single Responsibility Principle is concerned with classes, while the Interface Segregation Principle is concerned with interfaces.

Dependency Inversion Principle

“A. High-level modules should not depend on low-level modules. Both should depend on abstractions.
B. Abstractions should not depend on details. Details should depend on abstractions.”

When you are designing REST API for the below use cases I will explain how the Solid principle is an advantage .it will be better you think and take time when you write any controller, handler, service, and DTO creation.

Normally programmers used to hurry direct into coding, I would suggest draw a blueprint of your design and analyze each principle and validate the blueprint and make changes and start coding.


Code that follows S.O.L.I.D. principles can be easily shared, extended, modified, tested, and refactored without any problems. With each real-world application of these principles benefits of the guidelines will become more apparent.

Anti-patterns and improper understanding can lead to STUPID code: Singleton, Tight Coupling, Un-testability, Premature Optimization, In-descriptive Naming, and Duplication. SOLID can help developers stay clear of these.

Java 8 | Spring | React | Angular | CI/CD | Microservices | Monitoring |Apache Kafka.