Anish's Notebook

Open Closed SOLID was written during the early 90's when changing the code and republishing took a lot of time. Now it just takes minutes to redeploy the code. Also nowadays with the agile way of developing software changes are bound to happen. We often have this tendency to try to gold-plate things or say, well, we have this specific problem, but if we just set a specific flag here or add an input argument to this function here , we could make this specific thing that we're trying to do into some sort of general purpose solution, and the problem with that is that it tends to lead to coupling and complexity.  Reused Abstractions Principle. So this is not a principle that's a part of the five SOLID principles, but it's very much related to the five SOLID principles, and basically it says, if you have abstractions, in this case, if you have interfaces or abstract-based classes, and those abstractions are not being reused by being implemented by various different c...

Single responsibility THINGS THAT BELONG TOGETHER SHOULD STAY TOGETHER What we're really aiming for when we're talking about SOLID code is supple code, code that's pliable, code that you can shape into different forms and where you can change the shape if it turns out that the original shape that you had in mind doesn't really correctly address the problem at hand. And this is very important, because you almost never have all the requirements up front. Even if you think you have all the requirements up front for a piece of software that you're programming, requirements change as you go along, and the point of writing SOLID code is to make the code so supple, so pliable, that when requirements change, you can also change the code to fit the new requirements. The purpose of SOLID is to make you more productive by making the code more maintainable. If the design is rigid, it signifies that does not accept change. We define a responsibility as a reason to change. ...