Understanding the SOLID principles (Commentary)

We tend to get excited when experimenting an orginazed concept such as Object Oriented Programming, we want to make full use of all its qualities, quirks, and virtues without taking into mind if we are actually harming the development of the program or project we are creating.

Thankfully for us reckless Object Oriented programmers, the SOLID principles offer some guidance as to what to and what not to use. Though, at first sight some of the most fundamental SOLID principles seem to be directly at conflict with OOP guidelines, we need to take a pragmatic aproach when looking at them:

-Single responsibility principle: The swiss army knife may have been one of the most useful, iconic, and creative inventions of human history, but most of its functionalities can be singled out in several individual tools that may acomplish the job more easily. This principle advocates for single-purpose classes.

-Open/Closed principle: Open for extention, closed for modification. Instead of swaping a class' behaviors, it might be better to add new ones, specially if there are classes that inherit said behaviors.

-Liskov substitution principle: Similar to the previous principle, this one advocates for nonmodification of inherited methods, as to ensure that both classes (base, and heir) are interchangeable in most concepts. Now this is a direct affront towards inheritance and polymorphism, two of the principal ideas behind Object Oriented Programming, but it will also make the code significantly more maintainable. Remember, pragmatism trumps all.

-Interface Seggregation principle: Similar to the single responsibility principle, this concept advocates for single purpose interfaces as to not burden a class with too many behaviors it will ultimately not use.

-Dependency inversion principle: Make sure to make your classes dependable of abstracts instead of concretes. Why? Concretes tend to change while abstracts are generally idle.

May be hard to acomodate these principles with what we know of OOP, but, for the sake of good code and good practices, it is worth the try.