Overview Of SOLID Principal

Solid Principal is nothing but an idea of design or concept to achieve Cohesion1 and Couplingusing different features of Object Oriented model given by any programming languages that helps to develop robust, flexible and maintainable software components.

There are already tons of article available on internet so not going into much theory explanation instead we would see how we can implement those principal using one of our favorite language to develop such software components.

However, before diving into code let us discuss at high level about SOLID.

SOLID stands for the following-

Initial Stands for Concept
S SRP Single responsibility principle

A class should have only a single responsibility means it should perform only one job or in other word only one reason to change the class code.
O OCP Open/Closed principle

Software entities should be open for extension, but closed for modification means once class or its functionality developed and tested properly then should not be any reason to change existing code to accommodate new features instead extend the class to achieve new features.
L LSP Liskov substitution principle

LSP is nothing but an extension of Open/Close principal where objects in a program should be replaceable with instances of their subtypes without altering base class.
I ISP Interface segregation principle

Client program should not be forced to use all members of interface which is not usable for that client so ISP tells to use smaller cohesive interface rather than single one.
D DIP Dependency inversion principle

DIP states that high level modules should not depend upon low level modules means creation of object of low level class should not depend upon high level class.

Demo application has all proper comments and sequence of code/classes which helps to have clear understanding of SOLID which is written in C#. However these understanding depends upon the knowledge of interface, class, virtual, abstract of OOPS.

Now the question is why should we consider SOLID principal while designing software?

Answer is here

These design and principal are the solution of well-known issues which we can face while software development so by following these theory we can develop such problem free components which reduces the development cost and timing and we can also deliver robust, flexible and extensible software components to client.

  1. Cohesion is nothing but a consistency or interrelation of jobs that class or module supposed to do. If class or modules does different verity of task for which class or module is not built then it is low cohesion and if it does only related task for which it is built then high cohesion;only methods relating to the intention of the class.

  2. Coupling is nothing but a degree of dependency with other classes or module so low coupling would mean that changing something major in one class should not affect the other classes or module whereas high coupling would make your code difficult to make changes as well as to maintain it, as classes are coupled closely together, making a change could mean an entire system revamp.

All good software design will go for high cohesion and low coupling.