Comprender el acoplamiento flojo / apretado en el "mundo real"

No diré qué "comunidad" porque quiero una explicación no sesgada, pero digamos que está creando un módulo reutilizable y ese módulo requiere más de 3 módulos dependientes y eliminar 1 de ellos causa un error de ruptura no solo en su aplicación como entero que usa este módulo, pero el módulo en sí.

Según tengo entendido (que debe estar equivocado), un sistema modular acoplado libremente no se romperá simplemente quitando un módulo. La aplicación aún debería ejecutarse, pero sin esa "característica" / módulo y el módulo en sí no debería hacer que todo no se ejecute simplemente porque no existe un módulo dependiente.

¿Esto esta mal? Si es así, si los módulos aún dependen del punto de que todo no funcione, ¿cuál es la diferencia entre un acoplamiento apretado / suelto?

No del todo --- quitar el módulo podría dañar el sistema. La idea detrás de los sistemas acoplados libremente es que el intercambio en un módulo completamente diferente funcionará bien siempre que el nuevo módulo cumpla con los mismos requisitos de interfaz que el anterior. Si estuviera estrechamente acoplado, el código circundante haría suposiciones sobre las partes internas y comenzaría a fallar si se introdujera un nuevo módulo.

El acoplamiento flexible es esencialmente la dependencia indirecta entre módulos sobre cómo pueden evolucionar.

Generalmente, cuando hay un sistema estrechamente acoplado, diferentes módulos / objetos tienen comportamientos muy específicos que asumen ese comportamiento de los objetos periféricos. Dichos objetos están vinculados / acoplados a comportamientos de otros módulos y no pueden reutilizarse de forma aislada ni en ningún otro contexto.

Dichos módulos, aunque son responsables de la funcionalidad individual, no pueden evolucionar independientemente o no pueden evolucionar.

Un ejemplo:

Digamos que tiene 3 objetos Shape(un objeto modelo) y Canvas(un elemento UI). Ahora

Suponga que un método shape.draw(Canvas)dibujará un objeto en el plano suministrado por el plano del lienzo.

Ahora, a veces las ventanas están parcialmente cubiertas y cambian de tamaño. En tales casos, el método anterior podría hacer algo como esto.

shape::draw(Canvas) {
   Rect.WindowLeft = Canvas.GetWindowRect.getLeftOffset(); 
   Rect.LeftPixel = Canvas.GetWindowRect.pixels() + Rect.WindowLeft; 
   ....  // like this get all co-ordinates. 

   draw_instance(Rect);  // This will draw the actual shape. 
}

Básicamente, aquí la función de dibujo recoge el rectángulo donde hay que dibujar cosas. Esto es fácil de entender (la gente podría llamar a esto simple ) código Sin embargo, este es un código extremadamente acoplado.

Imagina la situación:

• ¿Qué pasa si el mecanismo del lienzo para sostener ventanas ya no es un rectángulo?
• ¿Qué pasa si hay compensaciones adicionales que Canvas mantiene que es privado ?
• ¿Qué sucede si alguna otra aplicación quiere la misma forma pero ya no tiene una ventana GUI (por ejemplo, está creando imágenes y guardando en archivos)?

La causa raíz del problema es que el objeto shape sabe y, por lo tanto, está estrechamente relacionado con él Canvas.

Lo deseable es que se dé un conjunto de píxeles a la forma donde escribe; el shapeno debe tener (incluso implícito) conocimiento sobre dónde se escriben realmente los píxeles.

Depende, incluso de lo que especifiques como módulo. Algunas partes del sistema deben estar estrechamente acopladas (por ejemplo, sus entidades deben reutilizarse en toda la aplicación), pero algunos sistemas deben estar sueltos, ya sea con separaciones de interfaz o si estamos hablando de no romper la aplicación si quita el módulo , entonces ese módulo debe conectarse de alguna forma dinámica, tal vez a través del contenedor IoC o algo así.

Además, el acoplamiento estrecho significa que alguna parte depende de la implementación específica del módulo, no de la definición del módulo o algo así.