8.1 La descomposición lo es todo
Para mayor claridad, una imagen de un buen artículo "Desacoplamiento de sistemas orientados a objetos", que ilustra los puntos principales que se discutirán.
¿Sigues pensando que diseñar una arquitectura de aplicaciones es fácil?
8.2 Interfaces, ocultación de implementación
Los principios fundamentales para reducir el acoplamiento del sistema son los principios de programación orientada a objetos y el principio de encapsulación + abstracción + polimorfismo detrás de ellos.
Es por eso que:
- Los módulos deben ser "cajas negras" entre sí (encapsulación) . Esto significa que un módulo no debe "treparse" a otro módulo y saber nada sobre su estructura interna. Los objetos de un subsistema no deben acceder directamente a los objetos de otro subsistema.
- Los módulos/subsistemas deben interactuar entre sí solo a través de interfaces (es decir, abstracciones que no dependen de los detalles de implementación). En consecuencia, cada módulo debe tener una interfaz o interfaces bien definidas para interactuar con otros módulos.
El principio de "caja negra" (encapsulación) nos permite considerar la estructura de cada subsistema independientemente de otros subsistemas. El módulo, que es una "caja negra", se puede cambiar con relativa libertad. Los problemas pueden surgir solo en la unión de diferentes módulos (o un módulo y un entorno).
Y esta interacción debe describirse en la forma más general (abstracta), es decir, en forma de interfaz. En este caso, el código funcionará igual con cualquier implementación que se ajuste al contrato de interfaz. Es esta capacidad de trabajar con diferentes implementaciones (módulos u objetos) a través de una interfaz unificada lo que se denomina polimorfismo.
Por eso Servlet es una interfaz : el contenedor web no sabe nada de servlets, para ello son unos objetos que implementan la interfaz Servlet y listo. Los servlets también saben un poco sobre la estructura del contenedor. La interfaz Servlet es ese contrato, ese estándar, esa mínima interacción que se necesita para hacer que las aplicaciones web de Java dominen el mundo.
El polimorfismo no es en absoluto la anulación de métodos, como a veces se cree erróneamente, sino ante todo, la intercambiabilidad de módulos/objetos con la misma interfaz o “una interfaz, muchas implementaciones”. Para implementar el polimorfismo, el mecanismo de herencia no es necesario en absoluto. Esto es importante de entender porque la herencia en general debe evitarse siempre que sea posible .
Gracias a las interfaces y al polimorfismo, es precisamente la capacidad de modificar y ampliar el código sin cambiar lo que ya está escrito (Principio Abierto-Cerrado).
Siempre que la interacción de los módulos se describa exclusivamente en forma de interfaces y no esté vinculada a implementaciones específicas, tiene la oportunidad de reemplazar absolutamente "sin dolor" para el sistema un módulo con cualquier otro que implemente la misma interfaz, así como agregue uno nuevo y, por lo tanto, amplíe la funcionalidad.
Es como en el constructor LEGO: la interfaz estandariza la interacción y sirve como una especie de conector donde se puede conectar cualquier módulo con un conector adecuado.
La flexibilidad del diseñador está asegurada por el hecho de que podemos simplemente sustituir un módulo o pieza por otra con los mismos conectores (con la misma interfaz), así como añadir tantas piezas nuevas como queramos (al mismo tiempo, las existentes). las piezas no se cambian ni alteran de ninguna manera).
Las interfaces le permiten construir un sistema más simple, considerando cada subsistema como un todo e ignorando su estructura interna. Permiten que los módulos interactúen y, al mismo tiempo, no saben nada sobre la estructura interna de cada uno, implementando así completamente el principio de conocimiento mínimo, que es la base del acoplamiento flexible.
Cuanto más generales/abstractas se definan las interfaces y menos restricciones impongan a la interacción, más flexible será el sistema. A partir de aquí, se sigue uno más de los principios de SOLID: el Principio de segregación de la interfaz , que se opone a las "interfaces gruesas".
Él dice que las interfaces grandes y voluminosas deben dividirse en otras más pequeñas y específicas, de modo que los clientes de interfaces pequeñas (dependiendo de los módulos) solo conozcan los métodos con los que necesitan trabajar.
Este principio se formula de la siguiente manera: “Los clientes no deben depender de métodos (ser conscientes de los métodos) que no utilizan” o “Muchas interfaces especializadas son mejores que una universal”.
Resulta que la conectividad débil se proporciona solo cuando la interacción y las dependencias de los módulos se describen solo con la ayuda de interfaces, es decir, abstracciones, sin usar el conocimiento sobre su estructura interna y estructura Y, de hecho, se implementa la encapsulación. Además, tenemos la capacidad de expandir/cambiar el comportamiento del sistema agregando y usando diferentes implementaciones, es decir, debido al polimorfismo. Sí, llegamos de nuevo a OOP - Encapsulación, Abstracción, Polimorfismo.
8.3 Fachada: interfaz del módulo
Aquí un programador experimentado preguntará: si el diseño no está al nivel de los objetos que implementan las interfaces correspondientes, sino al nivel de los módulos, ¿cuál es la implementación de la interfaz del módulo?
Respuesta: hablando en el lenguaje de los patrones de diseño, entonces un objeto especial puede ser responsable de la implementación de la interfaz del módulo - Fachada . Si está llamando a métodos en un objeto que contiene el sufijo Gateway (por ejemplo, MobileApiGateway), lo más probable es que sea una fachada.
Una fachada es un objeto de interfaz que acumula un conjunto de operaciones de alto nivel para trabajar con un determinado subsistema, ocultando su estructura interna y la verdadera complejidad detrás de él . Proporciona protección contra cambios en la implementación del subsistema. Sirve como un único punto de entrada: "usted patea la fachada y él sabe a quién debe patear en este subsistema para obtener lo que necesita".
Acaba de conocer uno de los patrones de diseño más importantes que le permite utilizar el concepto de interfaces al diseñar módulos y, por lo tanto, desacoplarlos: "Fachada".
Además, "Fachada" permite trabajar con módulos de la misma manera que con objetos ordinarios y aplicar todos los principios y técnicas útiles que se utilizan en el diseño de clases al diseñar módulos.
Nota : aunque la mayoría de los programadores entienden la importancia de las interfaces al diseñar clases (objetos), parece que muchos descubren la idea de usar interfaces también a nivel de módulo.