S.O.L.I.D Programming Principles of Object Oriented Design

SOLID is an acronym for the set of 5 object-oriented programming principles that every software developer must be aware of. These principles, when combined together, help in writing programs which are easy to maintain, extends, refactor and add new functionalities to the existing code base.

Before, we go ahead a start digging into what these 5 principles are, lets first understand what S.O.L.I.D stands for:

    #S: Single Responsibilty Principle
    #O: Open-Closed Principle
    #L: Liskov Substitution Principle
    #I: Interface Segregation Principle
    #D: Dependency Inversion Principle

Now, let's understand what each of these principle states and how can we write better programs using them.

Single Responsibility Principle

This principle states that each class should have just one job and should have just one reason to change. This principle doesn't mean that every class should have just one method but means that all the methods and properties of the class should collectively serve only one purpose.

Detailed description of Single Responsibility Principle of Object Oriented Design.

Open-Close Principle

This principle states that a class should be open to extensions and closed to modifications. What this means is that your code should be extensible without making any changes to existing classes.

Liskov Substitution Principle

This principle states that every derived class should be substitutable for its base class. If I further simplify this principle, then it states that every pointer to a base class should be able to use objects of derived class.

Interface Segregation Principle

According to this Interface Segregation Principle, no class should be forced to implement methods its not going to use. In simple terms, if a class if not going to use any interface, then don't implement that interface or not going to use any method, then don't implement that method. If an interface has many methods and a particular class is not going to use that method, then we need to segregate these into two different interfaces.

Dependency Inversion Principle

This principle states that every entity must depend on abstraction rather than concretion. Again, in simple terms this principles states that every higher level module should not depend on a specific entity, but should depend upon abstraction or interfaces. Programatically speaking, a class should not depend on another but but should be dependent on an interface, this will make our code more extensible.

Phew!! All done

This article is meant to introduce you people to basic of SOLID programming principles. I have written, more detailed versions of each principle of SOLID programming principles which should help you further grasp these principles.