Understanding the SOLID Principles

Understanding the SOLID principles

All of this thing of how to develop and write code starts to feel repetitive, I've seen it a lot of times along my college educations that it begins to feel obvious how this principles, recommendations, better practices and all of those thing work, it is obvious now to me what they try to tell.....maybe all this over-teaching accomplished one of its goals after all.

But it is funny to me how at some point all these points seem to contradict at some point and with the flow of time, first design, planning and a lot of diagrams were needed but from the shadows emerged agile programming and f*+ck all that. With these principles, specifically the Open/Closed and the Liskov Substitution principle, inheritance (one of the main things that makes object-oriented programming ... well ... object-oriented) is seen as the bad guy.

Nobody can deny that inheritance has its good side, it exists for one reason and in practice we can say that it is useful, however, for the actual demands I think it is needed way more or something different at all.

SOLID differentiates from the rest by being applied before coding not like refactoring that are done after that, I think that SOLID is a little concise, maybe because this reading is an extract but although this principles are good to have they don't deal with all the problems that may rise on a project, it is a nice beginning though.

While designing and developing software it is critical to determine what are we gonna do and how it is going to be done, because there are a lot of recommendations and principles for good design, a lot in fact that having a control to check if all of them are accomplished is almost impossible. Every programmer and team (or company) have its way of codding, they have a defined set of principles to follow may be or may not be SOLID or an abstraction of them but I think that SOLID is like a basic to understand and follow.