Nombre: Derek André Menéndez Urizar

Principios Solid
Podemos decir que SOLID no es una tecnología ni mucho menos una metodología, sino que es un acrónimo de
un conjunto de prácticas las cuales al utilizarse todas harán que nuestro software sea altamente mantenible,
extensible y robusto. Si bien no es una metodología estos principios están ligados a un desarrollo ágil y por lo
tanto nos permiten desarrollar de una manera rápida y que nuestro código no se vea afectado por los futuros
cambios.

Para empezar, tenemos la S el cual es el principio de una sola responsabilidad y es aquel en donde cada clase
debería tener una sola responsabilidad puesto que esto implica que solamente tendrá una sola razón para
cambiar y por lo tanto si se llega a modificar afecte la menor cantidad de funcionamiento del software. Cabe
destacar que en este principio se debería tener alta cohesión en las clases y esto quiere decir que la clase
internamente utiliza sus propios elementos internos, si hay muchos métodos en una clase que no se
encuentran entrelazados quizá estos deberían ir en clases a parte y dejar su funcionalidad en términos de una
sola responsabilidad. Lo anterior no sonará tan bien puesto que la idea de tener muchas clases muchas veces
no les gusta a los programadores, sin embargo, es mucho más fácil ver un sistema pieza por pieza que encontrar
un rompecabezas completo en una sola clase y que todo cambio afecte mi rompecabezas completo.

Con la O tenemos el principio de Abierto-Cerrado el cual se debe aplicar a todas las entidades que tengamos
en nuestro software y que cada una de ellas deberían estar cerradas a la modificación, pero siempre deberían
estar abiertas a la extensión y esto quiere decir que si bien nosotros tenemos una clase que tiene una
responsabilidad en específico esta responsabilidad debería poder implementarse o mejorarse de diferente
forma en una clase distinta sin afectar lo que ya se encuentra en la misma.

La L es el principio de sustitución de Liskov quien fue el que estableció el mismo. En este principio se dice que
cualquier clase hija debería poder ser reemplazada por la clase padre y que esto no cause ningún problema en
el código. Esto tiene mucho sentido ya que como programador no debería importarme como esta
implementada internamente la clase yo debería poder realizar cualquier acción con ella sin necesidad de saber
qué tipo de clase es ya que en caso contrario si yo no implemento este principio se debería hacer un if por cada
implementación que haya realizado de una clase en mi software para que yo fuera de la misma le diga cómo
tiene que trabajar internamente y eso hace que el software no sea escalable.

La I es el principio de segregación de interfaces y se dice que no se debe obligar al programador a utilizar

métodos que realmente no va a utilizar en la clase donde está implementando esa interfaz y esto, aunque a
simple vista parece simple es de gran importancia para no tener código de más en nuestras clases y que peor
aún no se esté utilizando ese código porque realmente no sirve para nada en esa clase, rompiendo así con el
principio S en cuanto a cohesión.

Por último y no menos importante la D es el principio de Inversión de dependencias y en este la misión principal
es desacoplar las clases, si bien nos han enseñado desde nuestros inicios en la programación que la
programación orientada a objetos nos permite hacer relaciones entre objetos esto hay que evitarlo en la
medida de lo posible puesto que entre más están acopladas las clases más es difícil de mantener o modificar
el software. Para ello se utilizan abstracciones de tal manera que una clase interactúe con otra sin que se
conozcan directamente, por ejemplo, una clase que sirva de puente entre la clase A(padre) y B que realice
todas las instancias que B no debería conocer de A y así seguir teniendo el código mantenible.

En conjunto los principios SOLID nos permiten hacer un código no solo eficiente sino que este siga siendo
reutilizable con el paso del tiempo y que las modificaciones que sean necesarias afecten el menor número de
piezas y por lo tanto se lleve a cabo en la menor cantidad de tiempo.