S.O.L.I.D Principles

S.O.L.I.D is an acronym for 5 Object Oriented principles introduced by
Robert C. Martin. They are a set of rules and best practices that should be followed when designing software in order to make the software design more understandable, flexible and maintainable

The 5 principles are :

i. Single Responsibility
ii. Open-close
iii. Liskov Substitution
iv. Interface Segregation
v. Dependency Inversion

Single Responsibility Principle

“A class should have only one job and should have one and only one reason to change”

This principle states that a class should have only one responsibility and therefore it should have only one reason to change. That one reason may be the business logic or database logic in the software specification that should be able to influence the specification of the class.

Open-Close Principle

“Objects or entities should be open for extension, but closed for modification”

Modification means altering an existing class code, and extension means adding new features.

This principle states that classes should allow its behaviour to be extended without modifying the source code. This statement can further be simplified as, we can add new implementations for the entities by inheriting classes and/or implementing interfaces instead of altering the source code.

Liskov Substitution Principle

“Every subclass or derived class should be able to substitute their parent class or base class”

This principle states that Inheritance should only be used if the superclass is replaceable by the subclass in all the instances. Therefore, child class should not have unimplemented methods and by overriding, they should not change the original meaning of the method in the base class.

Interface Segregation Principle

“Clients should not be forced to implement methods they do not use”

This principle is about separating the interfaces. It states that many client-specific interfaces are better than one general-purpose interface. The dependency of one class to another one should depend on the smallest possible interface. Therefore, we should keep the interfaces as small as possible.

Simply we should not add additional functionality to an existing interface by adding new methods instead we should create a new interface and let the class implement multiple interfaces as needed. Therefore, a class will not be forced to implement a function they do not need.

Dependency Inversion Principle

“Entities must depend on abstractions, not on concretions. It states that the high level module must not depend on the low level module, both should depend on abstractions”

The general concept of this principle is that High level modules should be easily reusable and unaffected by modifications to low level modules. A class that executes an action with a tool is a High level module. Low level module is a tool required to perform the action and help the high level do their work. Abstraction is an interface that links the two classes. The main aim of this principle is to reduce dependency of a high level class on the low level class by introducing an interface between them.