Acoplamiento/cohesión

Question

Si bien hay muchos buenos ejemplos en este foro que contienen ejemplos de acoplamiento y cohesión, estoy luchando por aplicarlo a mi código por completo. Puedo identificar piezas en mi código que pueden necesitar cambiar. ¿Los expertos en Java podrían echar un vistazo a mi código y explicarme qué aspectos son buenos y malos? No me importa cambiarlo yo mismo. Es solo que muchas personas parecen estar en desacuerdo entre sí y me resulta difícil entender qué principios seguir ...

Answer 1

Puedo recomendar el libro de Alan y James Patrones de diseño explicados: una nueva perspectiva sobre el diseño orientado a objetos (ISBN-13: 978-0321247148):

Es un gran libro sobre tiene un y es un decisiones, incluida la cohesión y el acoplamiento en el diseño orientado a objetos.

Answer 2

Primero, me gustaría decir que la razón principal por la que obtienes respuestas tan diferentes es que esto realmente se convierte en un arte con el tiempo. Muchas de las opiniones que obtienes no se reducen a una regla o un hecho rápido, más se reduce a la experiencia general. Después de 10-20 años haciendo esto, comienzas a recordar qué cosas hiciste que causaron dolor y cómo evitaste volver a hacerlas. Muchas respuestas funcionan para algunos problemas, pero es la experiencia del individuo la que determina su opinión.

Realmente solo hay 1 gran cosa que cambiaría en su código. Consideraría investigar lo que se llama el patrón de comando. La información sobre esto no debería ser difícil de encontrar en la web o en el libro de GoF.

La idea principal es que cada uno de sus comandos "agregue el niño", "Agregar padre" se convierta en una clase separada. La lógica para un solo comando está encerrada en una sola clase pequeña que es fácil de probar y modificar. Esa clase debe ser "ejecutada" para hacer el trabajo desde su clase principal. De esta manera, su clase principal solo tiene que lidiar con el análisis de la línea de comandos y puede perder la mayor parte de su conocimiento de un FamilyTree. Solo tiene que saber qué línea de comando se asigna en qué clases de comando y los comienzan.

Esos son mis 2 centavos.

Answer 3

En breve:

La cohesión en la ingeniería de software, como en la vida real, es cuánto los elementos consisten en un todo (en nuestro caso, digamos una clase), se puede decir que en realidad pertenecen juntos. Por lo tanto, es una medida de cuán fuertemente relacionada es 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 en la clase están utilizando alguno de los atributos privados.

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

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

El acoplamiento suelto 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 prácticamente posible ...

En mucho tiempo:

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. Creo que podría ayudar ...

Answer 4

El acoplamiento define el grado en que cada componente depende de otros componentes del sistema. Dados dos componentes A y B, cuánto código en B debe cambiar si A cambia. La cohesión define la medida de cuán coherentes o fuertemente relacionadas son las diversas funciones de un solo componente de software. Se refiere a lo que hace la clase. La baja cohesión significaría que la clase realiza una gran variedad de acciones y no se centra en lo que debe hacer. La alta cohesión significaría que la clase se centra en lo que debería estar haciendo, es decir, solo métodos relacionados con la intención de la clase. Nota: Las buenas API exhiben un acoplamiento suelto y una alta cohesión. Una forma particularmente aborrecible de acoplamiento estrecho que siempre debe evitarse es tener dos componentes que dependen entre sí directa o indirectamente, es decir, un ciclo de dependencia o dependencia circular. Información detallada en el siguiente enlacehttp://softwarematerial.blogspot.sg/2015/12/coupling-and-cohesion.html