The SOLID Design Principles

Classes are the building blocks of your java application. If these blocks are not strong, your building (i.e. application) is going to face the tough time in future. This essentially means that not so well-written can lead to very difficult situations when the application scope goes up or application faces certain design issues either in production or maintenance.

In this article, I will list down most recommended design principles that you should keep in mind, while writing your classes. These design principles are called SOLID, in short. These principles Make easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to easily refactor code, avoid code smells and are also a part of the agile or adaptive software development.

SOLID design principles are :

S - Single-responsiblity principle

O - Open-closed principle

L - Liskov substitution principle

I - Interface segregation principle

D - Dependency Inversion Principle

S - Single-responsiblity principle

Making sure that a class has a single responsibility makes it per default also easier to see what it does and how you can extend/improve it.

Classes that are hard to unit test are often breaking SRP.
"One class should have one and only one responsibility."

Open-closed principle

Open/Closed principle says that a class should be open for extension but closed for modification. Which means that you can add new features through inheritance but should not change the existing classes (other than bug fixes).

The reason is that if you modify a class, you’ll likely break the API/Contract of the class which means that the classes that depend on it might fail when you do so. If you instead inherit the class to add new features, the base contract is untouched and it’s unlikely that dependent classes will fail.

“Software components should be open for extension, but closed for modification.”

L - Liskov substitution principle

Any child type of a parent type should be able to stand in for that parent without things blowing up.

For example : if you have a Animal class with a MakeNoise() method, then any subclass of Animal should reasonably implement MakeNoise(). Dogs should bark, Cats should meow etc. What you wouldn't do is define a MuteMouse class that throws IDontActuallyMakeNoiseException. This violates the LSP, and the argument would be that this class has no business inheriting from Animal.

"Derived class or sub class must enhance functionality, but not reduce them."

I - Interface segregation principle

A client should never be forced to implement an interface that it doesn't use or clients shouldn't be forced to depend on methods they do not use.

For example : Developer Ravi created an interface Reportable and added two methods generateExcel() and generatedPdf(). Now client ‘A’ wants to use this interface but he intend to use reports only in PDF format and not in excel. Will he achieve the functionality easily.

Solution is to create two interfaces by breaking the existing one. They should be like PdfReportable and ExcelReportable. This will give the flexibility to user to use only required functionality only.

“Clients should not be forced to implement unnecessary methods which they will not use.”

D - Dependency Inversion Principle

Most of us are already familiar with the words used in principle’s name. It says:

“Depend on abstractions, not on concretions”

The classical use of this principle of BeanFactory in spring framework. In spring framework, all modules are provided as separate components which can work together by simply injected dependencies in other module. They are so well closed in their boundaries that you can use them in other software modules apart from spring with same ease.

Happy Learning !!!