All of the programmers might have heard of SOLID principles in Object Oriented Programming. This article is the first part of the SOLID principles series. In this article, I’m going to give you an introduction of what are those principles and why do the programmers or developers need it.

So, here we go.

Some facts you should know before beginning

Before you learn what really are SOLID principles and how to implement those principles in your development project, I would like you to know some important facts that you MUST know about SOLID principles.

1. First and foremost, these are principles, not rules.

2. Always use and follow the SOLID principles, but DO NOT try to achieve it. Because, if you try to achieve it, you may find it super hard to implement. So, always use SOLID as a tool for attaining good quality and maintainability in your programming projects.

3. Always use common sense while applying SOLID principles in your code project.

Ok. Now, what’s this SOLID principle?

Robert Martin(Uncle Bob) introduced some coding principles in his 2000 paper Design Principles and Design Patterns, which later given an acronym SOLID by Michael Feathers around 2004. In short, SOLID stands for the following five basic design principles. I have provided a short description of what they mean.

1. Single responsibility principle

   A class should have one, and only one, reason to change.

2. Open/Close principle

   Entities should be open for extension, but closed for modification.

3. Liskov’s substitution principle

   Derived classes must be substitutable for their base classes.

4. Interface Segregation principle

   Make fine grained interfaces that are client specific.

5. Dependency inversion principle

   Client should depend on abstractions, not on concretions.

Although it takes some time to understand what and how to apply these principles in your coding project, when applied in proper way SOLID principles makes your code more flexible, maintainable, easy to handle and less chance for bugs on adding new features.

In upcoming articles of this series, I’ll be discussing each design principle in detail.