You are here
Home > Android > Java Design Principles

Java Design Principles

SOLID Principles


SOLID is an acronym stands for five important design principles in Object Oriented Programming.

  • S: Single Responsibility Principle
  • O: Open-Closed Principle
  • L: Liskov Substitution Principle
  • I: Interface Segregation Principle
  • D: Dependency Inversion Principle


The SOLID design principles were introduced by Robert C. Martin and are some of the best-known design principles in object-oriented software development.

Each principles has its own importance and stand on it own however, they complement each other, so using them together makes the implementation of each principle robust and more effective.

Single Responsibility Principle



Any class , module or method should one and only one reason to change it .


Class, module or method should have one and only one responsibility.

How it helps :

  • Reduces the coupling between the two modules or classes.
  • Hence increases Code Modularity.


Open Closed Principle


Any Classes, modules or methods should be Open for extension (new functionalities) and Closed for modification.

Why So ?

  •     Already tested code no more required to be changed.
  •     It is always risky to modify the existing functionalities.
  •      Flexible to use due to its extensibility.


Liskov’s Substitution Principle

Derived Types must be completely substitutes for their Base Types.

  • Methods which uses parent class type must work with object of child class without producing any undesired behavior.
  • This principle is just an extension of Open closed principle which says that any child class extending the parent class should not change the behavior of it.

Interface Segregation Principle 

Clients should not be forced to implement functionalities which they do not require.

How to do it ?

  • Segregate your interface to avoid the absolute code .
  • Allow Client to implement only what it needs.

Dependency Inversion Principle

Depend on abstractions, not on concretions.

1. It states that the high level modules(Complex logic) should not depend on low level modules(Utility features); both should depend on abstractions.

2.Abstractions should not depend on details. Details should depend on abstractions.

Similar Articles