At some point in our career, we have all written code that we considered good, but needed full code replacement later on, even though the functional change requested was very small. When this occurs, it is often an indication of lack of either understanding or correct application of the SOLID principles.
Several years ago, I attended a talk on the principles, and it prompted me to try to be more aware of applying them to my code. From this I learned several lessons, the most important one being that almost no one takes the time to determine if they apply them at all, let alone correctly. It caused me to add an additional iteration to all my coding and code-review in which I actively ask the question: “Is it SOLID?”
But simply knowing the SOLID principles is not enough; you need to understand the why and how as well, which are actually a lot harder. These are important as the principles themselves are somewhat open for interpretation, which complicates applying them significantly. In this talk, I won’t focus on each of the principles themselves, but I’ll use examples of breaking two of the lesser understood ones and the problems this causes to highlight the reason why SOLID development is so important.