SOLID: 5 Design Principles of Object-Oriented programming for clean code

, SOLID: 5 Design Principles of Object-Oriented programming for clean code

Imagine you have two racks of books.

The books in the first rack are arranged in a Chaotic manner and books in the other rack are arranged by category.

In which rack can you find a specific book fast?

Of-course on the second rack.

, SOLID: 5 Design Principles of Object-Oriented programming for clean code

If things are organized neatly, it is very easy to find a specific thing or to add new things to that list.

So while developing some application, if code is arranged neatly then it’s very easy to manage that code in the future.

Because of unorganized code, adding new features or changing old ones becomes a hectic task. To solve this problem SOLID design principles were designed.  

SOLID principles is a way of coding to avoid messy code. When a developer writes a buggy code without thinking, then the final product becomes too complex to maintain in the future.  

SOLID is an acronym for 5 design principles, which was introduced by Robert C Martin (Uncle Bob).

1. Single Responsibility Principle (SRP)

This is the first principle of SOLID. This states that a class should have only one reason to change.

This principle inspires developers to create layers in the application. Which results in clean code. According to SRP, Every class should have a single job to do.

2. Open-Closed principle

This is the second principle of SOLID, which states that every code should be open for extension, but closed for modification.

This simply means you should be able to extend a class or build something new, without touching old features.

3. Liskov’s Substitution Principle:

This principle was introduced by Barbara Liskov in 1987.

This principle states that

“Derived or child classes must be substitutable for their base or parent classes“.

4. Interface Segregation Principle

This 4th principle of SOLID states that:

Clients should not be forced to depend upon interfaces that they do not use.

5. Dependency Inversion Principle

This principle states that :

High-level modules/classes should not depend on low-level modules/classes. Both should depend upon abstractions.

When a developer prefers to write code by using SOLID design principles,

he can have multiple benefits. I have listed some important benefits here:

1. Easy to understand

 As solid states that, every class must have only one reason to change, means indirectly it states that one should write clean code,

  And hence the product will be less buggy.

2. Easy to maintain

To maintain any product in the future, the flow of coding should be easy to understand.

  So the Open close principle plays an important role here to guide a developer on how to write an easy and maintainable code.

 If the developer follows SOLID, the resultant code will be easier to understand and debug.

Solid in short is a bunch of rules about a class:

S.Split it (don’t overdo it either)
O.Extend it (preferably abstraction)

L.Don’t fake it (preferably compose it)

I.Don’t enforce it (compose or inherit)

D.Inject it (don’t hardcore dependencies, use abstractions)

Leave a Reply