¡Descarga Principios solid para las buenas prácticas y más Esquemas y mapas conceptuales en PDF de Ingeniería del Software solo en Docsity!
Principios SOLID
Ahora que conoces los principios básicos de diseño, veamos cinco que se conocen popularmente como los principios SOLID. Robert Martin los presentó en el libro Desarrollo ágil de software: principios, patrones y prácticas^1.
SOLID es una regla mnemotécnica para cinco principios de di- seño ideados para hacer que los diseños de software sean más comprensibles, flexibles y fáciles de mantener.
Como con todo en la vida, utilizar estos principios de forma descuidada puede hacer más mal que bien. El costo de apli- car estos principios en la arquitectura de un programa es que puede hacerlo más complicado de lo que debería. Dudo que exista un producto de software exitoso en el que se apliquen todos estos principios al mismo tiempo. Aspirar a estos princi- pios es bueno, pero intenta siempre ser pragmático y no tomes todo lo escrito aquí como un dogma.
- Agile Software Development, Principles, Patterns, and Practices : https://refactoring.guru/es/principles-book
54 Principios SOLID #
S
Principio de responsabilidad única
ingle Responsibility Principle
Una clase sólo debe tener una razón para cambiar.
Intenta hacer a cada clase responsable de una única parte de la funcionalidad proporcionada por el software, y haz que esa res- ponsabilidad quede totalmente encapsulada por (también puedes decir escondida dentro de ) la clase.
El principal objetivo de este principio es reducir la complejidad. No hace falta que inventes un diseño sofisticado para un progra- ma que tiene unas 200 líneas de código. Con un puñado de buenos métodos te irá bien. Los verdaderos problemas surgen cuando tu programa crece y cambia constantemente. En cierto punto, las cla- ses se vuelven tan grandes que ya no puedes recordar sus detalles. La navegación del código se ralentiza hasta ir a paso de tortuga y tienes que recorrer clases enteras o incluso un programa completo para encontrar algo específico. El número de entidades en el pro- grama supera tu capacidad cerebral y sientes que pierdes el con- trol sobre el código.
Hay más: si una clase hace demasiadas cosas, tienes que cambiarla cada vez que una de esas cosas cambia. Al hacerlo, te arriesgas a descomponer otras partes de la clase que no pretendías cambiar. Si sientes que te resulta difícil centrarte en un aspecto específico del programa cada vez, recuerda el principio de responsabilidad única y comprueba si es el momento de dividir algunas clases en partes.
55 Principios SOLID / S: Principio de responsabilidad única #
O
Principio de abierto/cerrado
pen/Closed Principle
Las clases deben estar abiertas a la extensión pero ce- rradas a la modificación.
La idea fundamental de este principio es evitar que el código exis- tente se descomponga cuando implementas nuevas funciones.
Una clase está abierta si puedes extenderla, crear una subclase y hacer lo que quieras con ella (añadir nuevos métodos o campos, sobrescribir el comportamiento base, etc.). Algunos lenguajes de programación te permiten restringir en mayor medida la extensión de una clase con palabras clave como final. Después de esto, la clase ya no está abierta. Al mismo tiempo, la clase está cerra- da (también puedes decir completa ) si está lista al 100 % para que otras clases la utilicen; su interfaz está claramente definida y no se cambiará en el futuro.
La primera vez que estudié este principio me confundieron las pa- labras abierta y cerrada , porque suenan mutuamente excluyentes. Pero en lo que respecta a este principio, una clase puede estar al mismo tiempo abierta (para la extensión) y cerrada (para la modificación).
Cuando una clase se ha desarrollado, probado, revisado e incluido en un framework o utilizada en una aplicación de cualquier otro modo, es arriesgado intentar juguetear con su código. En lugar de cambiar directamente el código de la clase, puedes crear una sub-
57 Principios SOLID / O: Principio de abierto/cerrado #
clase y sobrescribir las partes de la clase original que quieras que se comporten de otra forma. Lograrás tu objetivo sin descomponer clientes existentes de la clase original.
Este principio no está pensado para aplicarse a todos los cambios de una clase. Si sabes que hay un error en la clase, debes arreglar- lo; no crees una subclase para ello. Una clase hija no debe ser res- ponsable de los problemas de la clase padre.
Ejemplo
Tienes una aplicación de comercio electrónico con una clase Pedido que calcula los costos de envío, y todos los métodos de envío están incrustados dentro de la clase. Si necesitas aña- dir un nuevo método de envío, tienes que cambiar el código de la clase Pedido , arriesgándote a descomponerlo.
ANTES: tienes que cambiar la clase Pedido siempre que añades un nuevo método de envío a la aplicación.
58 Principios SOLID / O: Principio de abierto/cerrado #
la nueva clase cuando el usuario seleccione estos métodos de envío en la UI.
Esta solución tiene la ventaja adicional de que te permite mover el cálculo del tiempo de entrega a clases más relevan- tes, de acuerdo con el principio de responsabilidad única.
60 Principios SOLID / O: Principio de abierto/cerrado #
L
Principio de sustitución de Liskov^1
iskov Substitution Principle
Al extender una clase, recuerda que debes tener la capa- cidad de pasar objetos de las subclases en lugar de obje- tos de la clase padre, sin descomponer el código cliente.
Esto significa que la subclase debe permanecer compatible con el comportamiento de la superclase. Al sobrescribir un méto- do, extiende el comportamiento base en lugar de sustituirlo con algo totalmente distinto.
El principio de sustitución es un grupo de comprobaciones que ayudan a predecir si una subclase permanece compatible con el código que pudo funcionar con objetos de la superclase. Este concepto es fundamental al desarrollar bibliotecas y fra- meworks , porque otras personas utilizarán tus clases y no po- drás acceder directamente ni cambiar su código.
Al contrario que otros principios de diseño que están muy abiertos a la interpretación, el principio de sustitución incluye un grupo de requisitos formales para las subclases y, específi- camente, para sus métodos. Repasemos esta lista en detalle.
- Este principio debe su nombre a Barbara Liskov, que lo definió en 1987 en su trabajo Data abstraction and hierarchy : https://refactoring.guru/ liskov/dah
61 Principios SOLID / L: Principio de sustitución de Liskov #
◦ Digamos que tienes una clase con el método comprarGato(): Gato. El código cliente espera recibir cual- quier gato como resultado de ejecutar este método.
◦ Bien: Una subclase sobrescribe el método de esta forma: comprarGato(): GatoDeBengala. El cliente obtiene un gato de Bengala, que sigue siendo un gato, por lo que todo está bien.
◦ Mal: Una subclase sobrescribe el método de esta forma: comprarGato(): Animal. Ahora el código cliente se des- compone porque recibe un animal genérico desconocido (¿Un lagarto? ¿Un oso?) que no encaja con la estructura di- señada para un gato.
Del mundo de los lenguajes de programación de tipado diná- mico podemos extraer otro ejemplo negativo: el método base devuelve una cadena, pero el método sobrescrito devuelve un número.
- Un método de una subclase no debe arrojar tipos de excepcio- nes que no se espere que arroje el método base. En otras pala- bras, los tipos de excepciones deben coincidir o ser subtipos de los que el método base es capaz de arrojar. Esta regla proviene del hecho de que los bloques try-catch en el código cliente se dirigen a los tipos específicos de excepciones que más pro- bablemente arrojará el método base. Por lo tanto, una excep- ción inesperada puede colarse entre las líneas defensivas del código cliente y destrozar la aplicación.
63 Principios SOLID / L: Principio de sustitución de Liskov #
En la mayoría de lenguajes de programación modernos, sobre todo los de tipado estático (Java, C# y otros), estas reglas vienen integradas en el lenguaje. No podrás com- pilar un programa que viola estas reglas.
- Una subclase no debe fortalecer las condiciones previas. Por ejemplo, el método base tiene un parámetro con el tipo int. Si una subclase sobrescribe este método y requiere que el valor de un argumento pasado al método sea positivo (lan- zando una excepción si el valor es negativo), esto amplía las condiciones previas. El código cliente, que solía funcionar bien pasando números negativos al método, ahora se descompone si empieza a funcionar con un objeto de esta subclase.
- Una subclase no debe debilitar las condiciones posteriores. Di- gamos que tienes una clase con un método que trabaja con una base de datos. Se supone que un método de la clase siem- pre debe cerrar todas las conexiones de las bases de datos abiertas al devolver un valor.
Creaste una subclase y la cambiaste, de modo que las cone- xiones de la base de datos permanezcan abiertas para poder reutilizarlas. Pero puede que el cliente no sepa nada de tus in- tenciones. Debido a que espera que los métodos cierren todas las conexiones, puede que simplemente finalice el programa después de invocar el método, contaminando un sistema con conexiones de bases de datos fantasma.
64 Principios SOLID / L: Principio de sustitución de Liskov #
Ejemplo
Veamos un ejemplo de una jerarquía de clases de documento que violan el principio de sustitución.
ANTES: el método guardar no tiene sentido en un documento de solo lectura, por lo que la subclase intenta resolverlo reiniciando el comportamiento base en el método sobrescrito.
El método guardar de la subclase DocumentosDeSoloLectura arroja una excepción si alguien intenta invocarlo. El méto- do base no tiene esta restricción. Esto significa que el código cliente se descompondrá si no comprobamos el tipo de docu- mento antes de guardarlo.
El código resultante también viola el principio de abierto/ce- rrado, ya que el código cliente se vuelve dependiente de clases
66 Principios SOLID / L: Principio de sustitución de Liskov #
concretas de los documentos. Si introduces una nueva subcla- se de documento, necesitarás cambiar el código cliente para que lo soporte.
DESPUÉS: el problema se resuelve tras hacer a la clase de documento de solo lectura la clase base de la jerarquía.
Puedes resolver el problema rediseñando la jerarquía de cla- ses: una subclase debe extender el comportamiento de una superclase, por lo tanto, el documento de solo lectura se con- vierte en la clase base de la jerarquía. El documento de escri- tura es ahora una subclase que extiende la clase base y añade el comportamiento de guardar.
67 Principios SOLID / L: Principio de sustitución de Liskov #
Ejemplo
Imagina que creaste una biblioteca que facilita la integración de aplicaciones con varios proveedores de computación en la nube. Aunque en la versión inicial sólo soportaba Amazon Cloud, cubría todos los servicios y funciones de la nube.
En aquel momento asumiste que todos los proveedores en la nube tienen la misma amplitud de espectro de funciones que Amazon. Pero cuando hubo que implementar soporte para otro proveedor, resultó que la mayoría de las interfaces de la biblioteca eran de- masiado amplias. Algunos métodos describen funciones que otros proveedores de la nube no incluyen.
ANTES: no todos los clientes pueden satisfacer los requisitos de la abotargada interfaz.
69 Principios SOLID / I: Principio de segregación de la interfaz #
Aunque puedes implementar estos métodos y colocar algunas maquetas, no será una solución muy limpia. La mejor solución es dividir la interfaz en partes. Las clases capaces de imple- mentar la interfaz original pueden ahora implementar varias interfaces refinadas. Otras clases pueden implementar única- mente aquellas interfaces que tienen métodos que tienen sen- tido para ellas.
DESPUÉS: una interfaz abotargada se divide en un grupo de interfaces más detalladas.
Como sucede con otros principios, con éste también puedes ir demasiado lejos. No dividas una interfaz que ya es bastante específica. Recuerda que, cuantas más interfaces crees, más se complicará tu código. Mantén el equilibrio.
70 Principios SOLID / I: Principio de segregación de la interfaz #
El principio de inversión de la dependencia sugiere cambiar la dirección de esta dependencia.
- Para empezar, debes describir interfaces para operaciones de bajo nivel en las que se basarán las clases de alto nivel, pre- feriblemente en términos de negocio. Por ejemplo, la lógica de negocio debe invocar un método abrirInforme(archivo) en lugar de una serie de métodos abrirArchivo(x) , leerBytes(n) , cerrarArchivo(x). Estas interfaces cuentan como de alto nivel.
- Ahora puedes hacer las clases de alto nivel dependientes de esas interfaces, en lugar de clases concretas de bajo nivel. Esta dependencia será mucho más débil que la original.
- Una vez que las clases de bajo nivel implementan esas interfa- ces, se vuelven dependientes del nivel de la lógica de negocio, invirtiendo la dirección de la dependencia original.
El principio de inversión de la dependencia suele ir de la mano del principio de abierto/cerrado : puedes extender clases de bajo nivel para utilizarlas con distintas clases de lógica de negocio sin descomponer clases existentes.
Ejemplo
En este ejemplo, la clase de alto nivel — que se ocupa de in- formes presupuestarios — utiliza una clase de base de datos de bajo nivel para leer y almacenar su información. Esto sig- nifica que cualquier cambio en la clase de bajo nivel, como en el caso del lanzamiento de una nueva versión del servi-
72 Principios SOLID / D: Principio de inversión de la dependencia #
dor de la base de datos, puede afectar a la clase de alto nivel, que no tiene por qué conocer los detalles de almacenamiento de datos.
ANTES: una clase de alto nivel depende de una clase de bajo nivel.
Puedes arreglar este problema creando una interfaz de alto nivel que describa operaciones de leer/escribir y haciendo que la clase de informes utilice esa interfaz en lugar de la clase de bajo nivel. Después puedes cambiar o extender la clase de bajo nivel original para implementar la nueva interfaz de leer/ escribir declarada por la lógica de negocio.
73 Principios SOLID / D: Principio de inversión de la dependencia #
