As a developer, we write a lot of code daily, with a satisfaction that we have written a very good code. Next day, you come to the office and you come to know that the requirements have changed from the client or new requirements have been provided by client, in the existing functionality itself. So what you do, you start analyzing your existing code, create a plan to modify it and get the work done, thinking that this will be it, until next day, when the same concept is repeated. And now you are made to think what is the best technique you should have used to write code, which will require minimum change when required, easily scale-able and reusable. This is where these principles come into the role.
The term S.O.L.I.D. was introduced by Robert Cecil Martin, who is also known as Uncle Bob. S.O.L.I.D. is an acronym and stands for the 5 principles. Each of the letter in this is further having a 3 letter acronym, as per their names. These principles are based on the concepts, which allows us to create structure of code which is very easy to extend, re-use, and make changes, which may not break the existing code. The names of these principles are based on the goals which these principles satisfy.
We will be discussing these principles one by one. So the term S.O.L.I.D. stands for :
S – Single Responsibility Principle : It says that There should never be more than one reason for a class to change.
O – Open/Closed Principle : It says that Classes should be open for extension, but closed for modification.
L – Liskov’s Substitution Principle : It says that Derived types must be completely substitutable for their base types.
I – Interface Segregation Principle : It says that Clients should not be forced to depend upon interfaces that they do not use.
D – Dependency Inversion Principle : It says that
- High-level modules should not depend on low-level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend on abstractions.
S.O.L.I.D. principles vs Design patterns – Is S.O.L.I.D. same as the design patterns ?
No, these principles are not the same. They might sound quite close to these patterns especially the Structural patterns. But they are different. in their approach and their concept.
One important difference, which i have seen is that these principles focus more on the extension of the existing code classes rather then the modification, which is quite clear from the use of the Single responsibility and the Open/Closed principles . On the other hand, using the design patterns more or less will result in modification of the existing code and even sometimes you may find that design patterns may violate these principles, like, for example the use of the patterns like factory method or facade pattern. So more you study these concepts, more differences you will find.
Now the most important point of discussion is whether to go for learning these design patterns first or these principle. In my opinion, go for these principles first. This is because, i have been checking out the design patterns but suddenly i came to know about these principles. When i went through these principles, i found that these principles can act as the base of the design pattern, but not the other way around. You can extend your code much easily if you are using these principles, as compared to the use of design patterns. But this does not means that you should not go for the design patterns. You can improve your code writing drastically using these principles and patterns together and it will depend only on the situation that whether you can apply both at the same time or not.
Any thoughts on these, are welcome…!!!