Understanding the SOLID principles
The first interesting topic I find here is focused for the object-oriented programming, but even with that this in mind, we find it useful for other purposes. This might appear a little out of place, but the distinction here is necessary, because I've felt that some concepts are strongly related to the OOP. Anyways, we have here five solid principles for design and getting the code more intuitive and to avoid the most dependencies that we can.
The first principle is the "Single responsibility" one and the name is very explicit, it's for getting each class doing one and just one thing, this I see that applies for the methods too, getting in the example some problems for a method that does more than one task. I would ad to this that the name would explicitly say what does each method do, because this is also a problem clearly presented.
The second principle is called "Open/Closed principle" and refers to get the classes/functions to be open to the extension of them, but closed to the idea of modifications. I think that this principle is because of the necessity for adding new functionality and avoiding the problems that might represent changing a class or a method, the changes could affect other classes and the functioning of other methods, be affected by sub or super classes and things like that.
For the third principle we have the Liskov substitution I get that you can have the sub classes called for the functions that expects base classes in order to work with them,but without modifying the behavior of any of this two classes. I think this may be just for comfort and for getting code more explicit.
The fourth principle gets us to avoid writing huge and confusing interfaces with several responsibilities, instead getting several small interfaces and being wise at the time of implementing them into the classes. This gets us to understand better the job that each class or methods does just looking at the interfaces, and gets more order to our code.
The last principle recommend to get the dependencies into abstract classes or interfaces instead of concrete classes, this minimizes the dependencies needed and to get the tests better. In this way I can see that the abstraction also reinforces this approach of getting the code more clear. At last, every points in this article points in the same direction and gets us to simplify the understanding of the code, potentiates the abstraction, the reusability, the cohesion and some factors that gets better practices for the programmer.
The first principle is the "Single responsibility" one and the name is very explicit, it's for getting each class doing one and just one thing, this I see that applies for the methods too, getting in the example some problems for a method that does more than one task. I would ad to this that the name would explicitly say what does each method do, because this is also a problem clearly presented.
The second principle is called "Open/Closed principle" and refers to get the classes/functions to be open to the extension of them, but closed to the idea of modifications. I think that this principle is because of the necessity for adding new functionality and avoiding the problems that might represent changing a class or a method, the changes could affect other classes and the functioning of other methods, be affected by sub or super classes and things like that.
For the third principle we have the Liskov substitution I get that you can have the sub classes called for the functions that expects base classes in order to work with them,but without modifying the behavior of any of this two classes. I think this may be just for comfort and for getting code more explicit.
The fourth principle gets us to avoid writing huge and confusing interfaces with several responsibilities, instead getting several small interfaces and being wise at the time of implementing them into the classes. This gets us to understand better the job that each class or methods does just looking at the interfaces, and gets more order to our code.
The last principle recommend to get the dependencies into abstract classes or interfaces instead of concrete classes, this minimizes the dependencies needed and to get the tests better. In this way I can see that the abstraction also reinforces this approach of getting the code more clear. At last, every points in this article points in the same direction and gets us to simplify the understanding of the code, potentiates the abstraction, the reusability, the cohesion and some factors that gets better practices for the programmer.
Comentarios
Publicar un comentario