S.O.L.I.D Principles

What are SOLID principles? These are 5 principles object oriented principles in order to design software products or solutions. These principles are first introduced by Robert C. Martin, also is called as “Uncle Bob”. Adopting these practices can also be useful in avoiding code smells, refactoring code, and Agile or Adaptive software development.

Single Responsibility principle?

According to this rule, a class should have one and only one reason to change, meaning that a class should have only one job. It’s an issue if a class has more than one reason to change. A class should focus on a single task at a time.

Open/Closed principle?

The entities or the objects should be open for extension and close for modifications. Extension is when you a class that has 2 methods to calculate the are of the circle and square. but you have to add another method to calculate the area of a triangle as well. So you add another method to calculate the area of a triangle. This is Extension
Modification- is updating or modifying the method which calculate the area of a square or circle is modification.

Liskov substitution principle?

Every subclass/derived should be able to substitute or do/act on behalf of their parent/ base class. The child class cannot have unimplemented methods that are derived from the parent/base class.

• when extending the base class it should perform the functionalities of the base class.
• The child class should not have unimplemented methods.
• The child class should not give different meaning to the methods exit in the base class that is overridden.

Interface segregation principle?

According to this principle the clients should not be forced to implement methods they do not use.

If there is an interface that has draw method and calculateArea method, and if the client wants only draw method and does not need calculateArea method, the client is forced to implement, so it is the violation of the rule.

This kind of interfaces are called as Fat interfaces.

The best practice to follow this principle is to group methods into different interfaces each serving or implementing on different set of clients.

Dependency inversion principle?

• Higher Level modules (If there are any business change requirements then only the higher level modules would change, any other technical changes should not allow the higher level modules to change)
• The higher level modules should not depend on lower level modules, but should depend on abstraction.
  eg:- change in database should not allow the higher level module to change.

Some of the benefits of applying these principles are,

• Code reusability
• Maintainability
• Extensibility

So I hope you have got a brief understanding of the SOLID principles, look forward for more contents.