SOLID Design Principles for Developers

In my search of writing better code I came along with an Article about SOLID Prinicples. These principles helps to write better code in Medium to Big Projects. Robert C. Martins also known as “Uncle Bob” advocates SOLID Design Prinicples which helps Developers in Writing Clean code. In short are these presented here. While Microservices tends to be complexes software these Priniciples help them to create code which is simple, easy to understand and easy to extend.

SOLID: S stands for Single Responsibility Prinicple. Each class should have one Responsibility and Code should be divided in order to have chunks with each having single Responsibility. For example Book has many attributes like name, isbn, price but adding a method like savePageToFile is against Single Responsibility Priniciple. This could be corrected when we add this Method to a Persistance Class.

Benefits here are
1. Side effects are minimal.
2. There is only one reason to change this class.
3. Work can be divided easily in Developer Team

SOLID: O stands for Open Closed Prinicple. A Software System should be Open for extensions but closed for modifications. In other words, It should be taken care of that any change in future should be possible without changing the whole code.

1. Any change in market can be easily added.

SOLID: L stands for Liskov Substitution Principle, which states that any Child Classes should be subsitutable to the Parent class and should implements on Parent class any additional behaviour and not reduce or change. For example if Square is subclass of Rectangle then it should use all the Rectangle properties and can extends with additional methods to that, but it(Square) still can be used instead of its Parent class Rectangle.

SOLID I: stands for Interface Segregation Priniciple is nothing else as dividing complex Interface into many Interfaces which can be used then together with more flexibility. Here instead of adding many behaviours to a single interface out of which only partially are implemented its better to divide them into parts so that classes can implement as many interfaces as required and then we have clearity on which parts are implemented.

SOLID D: stands for Dependcy Inversion Priniciple is one the complex from all above. It tells that Classes from higher levels should not be dependent on Classes on Lower level classes. Both should be extracted to Interfaces. Interfaces should not be dependent on details but details should depend on Interfaces. Main point here is that we should code againt Interfaces.We should try to code againt abstractions and not against concrete classes.