The SOLID Principles

SOLID stands for few set of object oriented principles and these principles helps in making the source code robust, salable, and extensible.

SOLID is a mnemonic acronym and each of the letters in it stands for:

·        S - Single Responsibility Principle

·        O - Open Closed Principle

·        L - Liskov Substitution Principle

·        I - Interface Segregation Principle

·        D - Dependency Inversion Principle

Single ResponsibilityPrinciple :

"every class should have a single responsibility", and that responsibility should be entirely encapsulated by the class. There should only be a single reason for making the change to a class and every behavior/function of class should have just one reason to exist.

Open Closed Principle :

"software application source codes should be open for extension but should be closed for modification."

If module satisfy the open-closed principle that have two benefits, its “open for extension:” means module’s behaviors can be changed but “closed for modification”: it is not allowed to change. This can be achieved by using Inheritance

Benefits of Open/Closed Principle:

·         Loose coupling

·         Reduced risk of breaking existing functionality be adding/inheriting new classes

Liskov SubstitutionPrinciple :

"the derived classes should be perfectly substitutable for their base classes."

The object of a derived class should be able to replace an object of the base class without modifying the behavior of the base class.

Interface SegregationPrinciple :

"many client-specific interfaces are better than one general-purpose interface." and no clients should be forced to implement methods which it does not use and the contracts should be broken down to thin ones

Benefits of Interface Segregation Principle:

·               More granular and more specific interface intended to keep a system decoupled and thus easier to refactor, change, and redeploy.

·               Interface should be so smaller and more specific ones so that clients will only have to know about the methods that are of interest to them.

Dependency InversionPrinciple :

"depend upon abstractions, [not] concretions." the modules should be depend on the abstract type of module, not actual implemented concrete class.

This Principle helps to decouple code by ensuring that the class depend on abstractions rather than concrete class.

 Dependency Injection (DI) is an implementation of this principle

Thanks for Visiting!!