S.O.L.I.D - 5 Principles of Object Oriented Design

These principles, when combined together, make it easy for a programmer to develop software that are easy to maintain and extend. They also make it easy for developers to avoid code smells, easily refactor code, and are also a part of the agile or adaptive software development.

S.O.L.I.D Stands for:

Single Responsibility Principle

Open Closed Principle

Liskov Substitution Principle

Interface segregation Principle

Dependency Inversion Principle

Let's look for each principle in brief

Single Responsible Principle

States that class should have one and only reason to change, meaning that a class should have only one job.

In other words, you should write, change and maintain a class for only one purpose. If it is model class then it should strictly represent only entity. This will give you the flexibility to make changes in future without worrying the impacts of changes for another entity.

Open Closed Principle

Software components like Object or Entities should be open for extension, but closed for modification.

What does it mean?? It means that your classes should be designed such a way that whenever fellow developers wants to change the flow of control in specific conditions in application, all they need to extend your class and override some functions and that’s it.

Class should be extended by fellow team members without any modification.

Lisko’v Substitution Principle

This principle is a variation of previously discussed open closed principle. It says:.

Derived types must be completely substitutable for their base types. It means that the classes fellow developer created by extending your class should be able to fit in application without failure. Suppose if developer poorly extended some part of your class and injected into application then it should not break the application or should not throw exception.

Interface Segregation Principle

It is applicable to interfaces as single responsibility principle holds to classes. It says:

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

Take an example. Developer Alex 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.

NO. He will have to implement two methods, out of which one is extra burden put on him by designer of software. Either he will implement another method or leave it blank. So are not desired cases, right??

So what is the solution? 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.

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.

In other words. you should design your software in such a way that various modules can be separated from each other using an abstract layer to bind them together.

Happy Coding :)