The SOLID principles have garnered quite a lot of opinions over the years. Many have sung its praises for providing a good framework for writing high-quality, extensible, maintainable, and clear code. But in later years, it has garnered a lot of criticism for giving rise to overengineered solutions, encouraging heavily abstracted systems that are hard to understand.
In this series of blog posts, I want to dig into the details of SOLID, deeply analyzing each principle, apply them to real-world examples, and determine what we can learn from them, how they've been used/abused, and attempt to find the underlying effect that they were intended to achieve.
The reason I think this would be fruitful is because I believe a lot of SOLID's principles are in fact second-order principles. They specify a direction or a path, not an absolute goal. This stems from the simple observation that even avid SOLID proponents warn you against going "too far" in applying SOLID.
If you can go "too far" with something, what you've been described is not a goal, but rather a direction. The problem with recommending directions is that the right direction to travel in doesn't tell you how far to go, and depends on your starting point! What I'm hoping to get out of this analysis is attempting to specify the final destination, not the reactionary adjustments I believe SOLID was to the software environment of its time. Most of times there isn't a perfect answer, so if there are trade-offs involved in a design decision, I will make an attempt to state clearly what the trade-off is and not present something as a silver bullet.
First up will be the oft-misunderstood SRP - Single Responsibility Principle. I hope you'll be pleasently surprised by how different the "goal" of SRP is from what people usually intuit it's supposed to achieve!
Top comments (0)