SOLID: Principio abierto / cerrado

Este principio no trata acerca de los horarios de las tiendas, ni nada por el estilo (aunque estaría gracioso que así fuera...).


Sino más bien acerca del cambio al que se enfrenta una clase a lo largo de su vida. Este principio nos comenta que una clase debe estar abierta a la extensión pero cerrada a su modificación, o lo que es lo mismo, fácilmente extendible sin tener que modificarse.


Veamos un ejemplo:


Imaginemos que tenemos la clase Car:


public class Car {
    private String carRegistration;
    private double price;
    
    public Car () {...}
    
    ...

Bien, ya tenemos nuestra clase, que representa un coche con sus métodos necesarios, pero, imaginemos que ahora el fabricante quiere hacer coches que tengan barbacoas incluidas para comer (que buena idea), pero, no todos los coches la incluyen, los modelos antiguos no, y los nuevos modelos solo los que tengan esa especialidad ¿deberíamos crear un nuevo atributo para representar esto? La respuesta es no.


¿Y cuál es la principal razón?


Pues que si lo hiciéramos probablemente nuestra aplicación o sistema se vería afectado, muchos se preguntarán, ¿pero si es un atributo que le hace falta al coche debería incluirse? Cierto, pero no va a estar en todos los coches, es más será un tipo de coche totalmente diferente (incluir una barbacoa no será nada fácil), por tanto lo ideal sería crear una clase como la siguiente:


public class CarWithBBQ extends Car () {
    private BBQ bbq;
    ...
}

Espero que con este ejemplo se entienda, si se te ocurre algo mejor o tienes dudas, ya sabes, comentarios o redes sociales, ahí te espero, hasta la próxima :)



70 vistas0 comentarios

©2020 por Juanma Perez.