SOLID- Design Principles

The SOLID Principles of programming are a set of rules which when followed during designing and developing an object oriented application, will reap the following benefits.

• Loosely Coupled Application
•  Easily Extensible application
• Highly manageable code for maintenance

SOLID is an acronym that can be expanded as Below:

(I’ll first  get into theoretical aspect of it and then clarify it via code)

S: Single Responsibility Principle 

A class should do only one thing .

Logically speaking Separation of Concern and separation of responsibility is what we need to differentiate. This principle talks about responsibility not concern.

“My responsibility as a developer is to meet deadline and code as per the standards, if the client is not happy, that is none of my concerns (isn't it soothing…..)”

.Same goes with class, it should be doing only one thing at a time, if multiple responsibilities are entrusted to it(imagine you doing job of a co-coordinator, developer, designer, team leader all at one time…all you’ll become is jack of All, master of None).

In simpler terms, always make sure a class has ONE and ONLY ONE responsibility(it does not mean it should have only one functions though.)

O: Open / Closed Principle 

 A class should be open for extension but closed for modification. Classes should be designed so they can be inherited from without having to modify them.

While designing classes for any enterprise application, always keep in mind that the class should not be modified, however whenever there is a need, create another class and extend the base class.

L:Liskov Substitution Principle 

 Derived classes must be substitutable for their base class.

 When a class method accepts an object, the method should be able to accept children of that object.

If there is Base Class A and an inherited class B, wherever an object of A is expected and we instead pass an object of B, the code should work fine.(Simple OOPS right??...obviously the first thing that strikes the mind is Interfaces, don’t worry it’s next).

I:Interface Segregation Principle 

 Interfaces should be fine grained and only provide for current project needs. When building interfaces, never add more functionality than what is needed at the time.

Assume creating an Interface IMylife(that will sum up the gist of life.).Now let’s add some methods to it

Void childhoodmemories ();

Void MylifeAsTeenager();

Void MyYouth()

Void MyRetirement();

Void MyDeath()

Void MyNextLife()

Void MyNExtLifeChildhood()

Now let’s try to implement this interface, you’ll endup implementing your nextbirth(and all you wanted was implement your current).

In the current scenario, you’ll definitely throw not implemented exception in all the cases that does not hold true currently.

So the point is, just do the needful, planning next life is not such a good idea in the current life(am I getting boring..or too sarcastic?)

D: Dependency Inversion Principle 

High level modules should not depend on low level modules, but instead both should depend on abstractions. Interfaces should be used as placeholders and factory classes should be used to instantiate objects. This causes loose coupling between classes.

OOPs does it sound like Substitution principle?...well these principles does not work in isolation, they are used collectively to achieve the goals of designing.

I’ll start a series now to implement these principles in code starting form SOLID-Single Responsibility Principle.

Hope the information is useful,

Do remember to go to my next blog entry in this series.

Till next we connect…….

Happy Learning…..