Understanding the SOLID Principles

Hi, I will give my opinion about the book section “Understanding the SOLID Principles” by Edward Guiness, first of all, what is S.O.L.I.D? Well, according to the book section, it is an acronym that stands for five widely accepted principles of the OOP and design.

Single Responsibility Principle. (S)

First, lets talk about the Single Responsibility Principle, in general terms, the main purpose is that a class/function or whatever should have exactly one responsibility, as simple as that, this means that your system will have low coupling and high cohesion, and in the industry that's what we are looking for in all our systems, for example, when we are making changes in a function, with this principle, this change does not affect another function because as the single responsibility principle says, this function only does one responsibility, I agree with this principle because it makes our life as developers easier in order to code and mantein code of others.

Open/Closed Principle. (O)

This principle basically states that classes should be open for extension but closed for modification. in other words, should be created in order to be extended and not modified, this is a powerful principle and I agree with this principle because in software that demands many objects, for example, in video games development, it can give you a lo of advantages, for example, having a father main class in which subclasses can inherit methods that can overwrite them (in the subclass, not affecting the main class)and make extensions of this father main class, whit this principle it is possible to have more methods in this subclasses in order to do whatever they want in their environment.

Liskov Substitution Principle. (L)

In general terms, derived classes must be substitutable for their base classes, this is, for example, if you have a method that inside of the scope of this function has a class 'X' that does something in this function in order to get accomplish the responsibility of this function, but if you have a class 'Y' that it is a subclass of 'X' then if you replace the class 'X' with the class 'Y', it will not change the functionality of the method because it accomplishes the Liskov Substitution Principle.

Interface Segregation Principle. (I)

Be simple, make interfaces/classes that provide the necessary methods to accomplish the main objective of each class/interface, this is that we do not want to make a class /interface that provides methods that we are not going to use, instead of that, we want to create methods that are going to be used and are necessary to accomplish the objective of the class/interface. I agree with this principle because I think that if you are coding with having this in mind will produce to you a good habit of coding and our code will be simple, in consequence, it will be easier to read.

Dependency Inversion Principle. (D)

Last but not least is the dependency inversion principle, basically, it says that you need to depend on abstractions, not on concretions, this is that, for example, if you have a method or a class that, for example, has a constructor that initializes an instance, and this instance will have an attribute of a specific class (subclass) (using composition), it is better to change that and instead of having an attribute of a specific class, change it with an attribute of type 'superclass', as simple as that! The advantage of this is that now you can send any object that inherits from that superclass and you will be happy because you can assign it to the attribute.