Me interrogaron en una entrevista técnica sobre la cohesión y el acoplamiento de un proyecto. Le expliqué ampliamente sus definiciones, aunque no respondí la segunda parte de la pregunta correctamente, como él dijo.

"¿Cómo podríamos lograr un diseño altamente cohesivo y poco acoplado en un proyecto simultáneamente y explicar cómo debería implementarse este enfoque en un proyecto monolítico?"

Respondí que estos dos objetivos son contradictorios, por lo que necesitamos encontrar la mejor apuesta para cada proyecto o módulo, pero no pude proporcionar una respuesta integral.

Agradecería si alguien me ayudara.

6
Ali K. Nouri 9 sep. 2018 a las 21:23

3 respuestas

La mejor respuesta

Quiero comenzar a responder diciendo que es exactamente lo contrario de lo que usted dijo como "las dos definiciones son contradictorias". Voy a describirlo con una cita del libro John W. Satzinger System Analysis and Design in a Changing World, Facts

El bajo acoplamiento a menudo se correlaciona con una alta cohesión, y viceversa.


Al decir en un Monolítico le indicaban que preguntara sobre los Principios SÓLIDOS de que si los aplica, daría como resultado un proyecto de alta cohesión y acoplamiento flojo.

Aquí están las definiciones:

1.Principio de responsabilidad única (SRP)

Definición: Nunca debe haber más de una razón para que una clase cambie.

Beneficios:

  • mayor cohesión en la clase
  • acoplamiento más flojo entre clases de dependencia,
  • mejor legibilidad
  • código con menor complejidad
  • Código más fácil de entender y mantener.

2. Principio abierto-cerrado (OCP)

Definición: las entidades de software (clases, módulos, funciones, etc.) deben estar abiertas para extensión, pero cerradas para modificación.

Beneficios:

  • bajo acoplamiento,
  • mejorar la legibilidad
  • reduciendo el riesgo de romper la funcionalidad existente
  • Código mantenible y reutilizable.
  • Código más robusta.

3. Principio de sustitución de Liskov (LSP)

Definición: Los objetos en un programa deben ser reemplazables con instancias de sus subtipos sin alterar la corrección de ese programa.

Beneficios:

  • bajo acoplamiento
  • Código más reutilizable.
  • Jerarquías de clase fáciles de entender.

4. Principio de segregación de interfaz (ISP)

Definición: muchas interfaces específicas del cliente son mejores que una interfaz de uso general

Beneficios:

  • Sistema desacoplado.
  • Código fácil de refactorizar.

5. Principio de inversión de dependencia (DIP)

Definición: los módulos de alto nivel no deberían depender de módulos de bajo nivel, sino que ambos deberían depender de la abstracción. La abstracción no debe depender de los detalles; más bien el detalle debería depender de la abstracción.

Beneficios:

  • Alta cohesión.
  • Reducir el acoplamiento.
  • Código más reutilizable.

Más información


Libros

  • Código de Steve McConnell completo
  • Código limpio del tío Bob
9
3 revs, 2 users 99% 10 sep. 2018 a las 09:29

De acuerdo a Wikipedia (https://en.wikipedia.org/wiki/Cohesion_ (computer_science))

La alta cohesión a menudo se correlaciona con un acoplamiento flojo y viceversa.

Por lo tanto, el objetivo es lograr una alta cohesión y acoplamiento flojo. Para lograrlo, necesita desarrollar clases que hagan solo una cosa, dividir el proyecto monolítico en varios módulos (DAO, UI, lógica de negocios) y programar en una interfaz para que otras clases (u otros módulos) no sepan nada sobre los componentes internos de otros clases / módulos y conoce solo contratos externos (interfaces / API).

2
Ivan 9 sep. 2018 a las 18:31

No estaba familiarizado con el concepto de cohesión antes de leer su pregunta. De Wikipedia (aquí):

Los módulos con alta cohesión tienden a ser preferibles, porque la alta cohesión está asociada con varios rasgos deseables de software, incluyendo robustez, confiabilidad, reutilización y comprensibilidad. Por el contrario, la baja cohesión se asocia con rasgos indeseables, como ser difícil de mantener, probar, reutilizar o incluso comprender.

La cohesión a menudo se contrasta con el acoplamiento, un concepto diferente. La alta cohesión a menudo se correlaciona con un acoplamiento flojo y viceversa.

Creo que desea una alta cohesión dentro de cada módulo y un acoplamiento flojo entre ellos, lo que se puede lograr al tener módulos para comunicarse solo a través de interfaces abstractas simples. Para definir estas interfaces, deberá diseñar una separación limpia de preocupaciones, donde todas las tareas estrechamente acopladas se realicen en la misma clase, mientras que las tareas con una granularidad diferente (por ejemplo, algoritmo de alto nivel versus detalle de implementación de bajo nivel) se separan y abstraído por interfaces.

2
Dici 9 sep. 2018 a las 18:34