¿Qué significa 'bajo en acoplamiento y alto en cohesión'?

Tengo problemas para entender la declaración low in coupling and high in cohesion. Busqué en Google y leí mucho sobre esto, pero aún me cuesta entenderlo.

Según entiendo High cohesion, significa que debemos tener clases especializadas para realizar una función en particular. Espero que esto sea correcto? Como una clase de validación de tarjeta de crédito, que está especializada para validar solo tarjetas de crédito.

¿Y todavía no entiendo lo que significa bajo acoplamiento?

Lo que creo es esto:

La cohesión se refiere al grado en que los elementos de un módulo / clase pertenecen juntos, se sugiere que el código relacionado debe estar cerca uno del otro, por lo que debemos esforzarnos por una alta cohesión y unir todos los códigos relacionados lo más cerca posible. Tiene que ver con los elementos dentro del módulo / clase.

El acoplamiento se refiere al grado en que los diferentes módulos / clases dependen unos de otros, se sugiere que todos los módulos sean independientes en la medida de lo posible, por eso el bajo acoplamiento. Tiene que ver con los elementos entre diferentes módulos / clases.

Para visualizar la imagen completa será útil:

La captura de pantalla fue tomada de Coursera .

La cohesión en la ingeniería de software, como en la vida real, es cuánto se puede decir que los elementos que consisten en un todo (en nuestro caso, digamos una clase) que realmente pertenecen juntos. Por lo tanto, es una medida de cuán fuertemente relacionada está cada pieza de funcionalidad expresada por el código fuente de un módulo de software.

Una forma de ver la cohesión en términos de OO es si los métodos de la clase están utilizando alguno de los atributos privados.

Ahora la discusión es más grande que esto, pero la alta cohesión (o el mejor tipo de cohesión: la cohesión funcional) es cuando se agrupan partes de un módulo porque todas contribuyen a una única tarea bien definida del módulo.

Acoplando en palabras simples, es cuánto sabe un componente (de nuevo, imagine una clase, aunque no necesariamente) sobre el funcionamiento interno o los elementos internos de otro, es decir, cuánto conocimiento tiene del otro componente.

El acoplamiento flojo es un método para interconectar los componentes en un sistema o red para que esos componentes dependan unos de otros en la menor medida posible ...

Escribí una publicación de blog sobre esto. Discute todo esto con mucho detalle, con ejemplos, etc. También explica los beneficios de por qué debe seguir estos principios.

En el diseño de software, la alta cohesión significa que la clase debería hacer una cosa y una muy bien. La alta cohesión está estrechamente relacionada con el principio de responsabilidad única .

El acoplamiento bajo sugiere que la clase debería tener las dependencias menos posibles. Además, las dependencias que deben existir deben ser dependencias débiles: prefiera la dependencia de la interfaz en lugar de la dependencia de la clase concreta, o prefiera la composición sobre la herencia.

La alta cohesión y el bajo acoplamiento nos dan un código mejor diseñado que es más fácil de mantener.

Respuesta corta y clara

• Alta cohesión : los elementos dentro de una clase / módulo deberían funcionar juntos y hacer una cosa en particular.
• Acoplamiento suelto : entre las diferentes clases / módulos debe existir una dependencia mínima.

El acoplamiento bajo está en el contexto de dos o muchos módulos. Si un cambio en un módulo resulta en muchos cambios en otro módulo, entonces se dice que están altamente acoplados. Aquí es donde ayuda la programación basada en la interfaz. Cualquier cambio dentro del módulo no afectará al otro módulo ya que la interfaz (el medio de interacción) entre ellos no ha cambiado.

Alta cohesión: unir las cosas similares. Por lo tanto, una clase debe tener métodos o comportamientos para hacer un trabajo relacionado. Solo para dar un mal ejemplo exagerado: una implementación de la interfaz List no debería tener una operación relacionada con String. La clase String debe tener métodos, campos que sean relevantes para String y, de manera similar, la implementación de List debe tener los elementos correspondientes.

Espero que ayude.

En pocas palabras, bajo acoplamiento, como entendí, significaba que los componentes se pueden intercambiar sin afectar el funcionamiento adecuado de un sistema. Básicamente modulice su sistema en componentes funcionales que se puedan actualizar individualmente sin romper el sistema

¿Tienes un teléfono inteligente? ¿Hay una aplicación grande o muchas pequeñas? ¿Una aplicación responde a otra? ¿Puedes usar una aplicación mientras instalas, actualizas y / o desinstalas otra? Que cada aplicación sea autónoma es una gran cohesión. Que cada aplicación sea independiente de las demás es de bajo acoplamiento. DevOps favorece esta arquitectura porque significa que puede realizar una implementación continua discreta sin interrumpir todo el sistema.

La herencia o generalización es un ejemplo de alto acoplamiento (es decir, alta interdependencia). Lo que quise decir con esto es que, en la herencia, a menudo la clase principal define las funcionalidades básicas que utiliza su clase secundaria y el cambio en los métodos de la clase principal afecta directamente a sus clases secundarias. Por lo tanto, podemos decir que existe un mayor grado de interdependencia entre clases.

La realización o el uso de la interfaz es un ejemplo de alta cohesión (es decir, baja interdependencia). Lo que esto significa es que una interfaz presenta un contrato para cualquier clase que lo implemente, pero cada clase tiene el derecho de implementar métodos declarados en la interfaz a su manera y los cambios en el método declarado en una clase no afectan a ninguna otra clase.

Cohesión : cuán estrechamente relacionado está todo entre sí.
Acoplamiento : cómo todo está conectado entre sí.

Tomemos un ejemplo: queremos diseñar un automóvil autónomo.

(1) Necesitamos que el motor funcione correctamente.

(2) Necesitamos que el automóvil conduzca solo.

Todas las clases y funciones en (1) arrancar el motor y hacerlo funcionar funcionan muy bien juntos, pero no ayudan al automóvil a conducir. Entonces colocamos esas clases detrás de un controlador de motor.

Todas las clases y funciones en (2) funcionan muy bien para hacer que el automóvil gire, acelere y frene. No ayudan al automóvil a arrancar ni a enviar gasolina a los pistones. Así que colocamos estas clases detrás de su propio controlador de conducción.

Estos controladores se utilizan para comunicarse con todas las clases y funciones disponibles. Los controladores luego se comunican solo entre sí. Esto significa que no puedo llamar a una función en la clase de pistón de la clase de acelerador para hacer que el automóvil vaya más rápido.

La clase de pedal tiene que pedirle al controlador de manejo que hable con el controlador del motor, que luego le dice a la clase de pistón que vaya más rápido. Esto nos permite a los programadores poder encontrar problemas y nos permite combinar grandes programas sin preocuparnos. Esto se debe a que todo el código funcionaba detrás del controlador.

El acoplamiento bajo y la alta cohesión es un fenómeno recomendado.

El acoplamiento significa en qué medida varios módulos son interdependientes y cómo se ven afectados los demás módulos al cambiar alguna / considerable funcionalidad de un módulo. Se enfatiza el acoplamiento bajo ya que la dependencia debe mantenerse baja para que se realicen cambios mínimos / insignificantes en otros módulos.

Un ejemplo puede ser útil. Imagine un sistema que genera datos y los coloca en un almacén de datos, ya sea un archivo en el disco o una base de datos.

Se puede lograr una alta cohesión separando el código del almacén de datos del código de producción de datos. (y de hecho separando el almacenamiento en disco del almacenamiento de la base de datos).

Se puede lograr un acoplamiento bajo asegurándose de que la producción de datos no tenga ningún conocimiento innecesario del almacén de datos (por ejemplo, no pregunte al almacén de datos sobre nombres de archivos o conexiones de base de datos).

Aquí hay una respuesta de un poco de un ángulo teórico gráfico abstracto:

Simplifiquemos el problema solo mirando gráficos de dependencia (dirigidos) entre objetos con estado.

Una respuesta extremadamente simple puede ilustrarse considerando dos casos limitantes de gráficos de dependencia:

El primer caso limitante : un gráfico de clúster .

Un gráfico de clúster es la realización más perfecta de un gráfico de dependencia de alta cohesión y bajo acoplamiento (dado un conjunto de tamaños de clúster).

La dependencia entre grupos es máxima (totalmente conectada), y la dependencia entre grupos es mínima (cero).

Esta es una ilustración abstracta de la respuesta en uno de los casos limitantes .

El segundo caso límite es un gráfico totalmente conectado, donde todo depende de todo.

La realidad está en algún punto intermedio, cuanto más cerca del gráfico de clúster, mejor, en mi humilde comprensión.

Desde otro punto de vista : cuando se mira un gráfico de dependencia dirigida, idealmente debería ser acíclico, si no, los ciclos forman los grupos / componentes más pequeños.

Un escalón hacia arriba / abajo de la jerarquía corresponde a "una instancia" de acoplamiento flojo, cohesión ajustada en un software, pero es posible ver este principio de acoplamiento flojo / cohesión ajustada como un fenómeno repetitivo a diferentes profundidades de un gráfico dirigido acíclico (o en uno de sus árboles de expansión).

Tal descomposición de un sistema en una jerarquía ayuda a vencer la complejidad exponencial (digamos que cada grupo tiene 10 elementos). Luego, en 6 capas, ya es 1 millón de objetos:

10 clústeres forman 1 supercúmulo, 10 supercúmulos forman 1 hipercúmulo, etc.

Entonces, esta podría ser la verdadera importancia de la historia y no solo la alta cohesión y el bajo acoplamiento solo dentro de dos capas. La importancia real se vuelve clara cuando se consideran las abstracciones de nivel superior y sus interacciones.

Creo que tiene muchas definiciones en rojo, pero en el caso de que todavía tenga dudas o en caso de que sea nuevo en la programación y quiera profundizar en esto, le sugeriré que vea este video, https://youtu.be/HpJTGW9AwX0 Es solo una referencia para obtener más información sobre el polimorfismo ... Espero que entiendas mejor con esto

Acoplamiento bajo: lo mantendrá muy simple. Si cambia su módulo, ¿cómo afecta a otros módulos?

Ejemplo: - Si su API de servicio se expone como JAR, cualquier cambio en la firma del método interrumpirá la API de llamada (acoplamiento alto / ajustado).

Si su módulo y otro módulo se comunican a través de mensajes asíncronos. Mientras reciba mensajes, la firma de cambio de método será local para su módulo (Acoplamiento bajo).

Por supuesto, si hay un cambio en el formato del mensaje, el cliente que llama tendrá que hacer algún cambio.