reducir acoplamiento

En términos generales, cuando una clase depende de otra hay algún nivel de acoplamiento. Entre más y más dependa más acoplamiento hay.

Ejemplo:

La herencia es la forma más fuerte que hay, porque todo el comportamiento del padre está en el hijo y no se pueden hacer ciertas cosas. Es por eso que hay que diseñar para heredar o sino prohibir la herencia.

La herencia aunque es la forma más fuerte de acoplamiento , no siempre es mala, porque si lo que deseamos es precisamente especializar una clase la mejor forma es heredando de ella, así que hay veces que eso es precisamente lo que queremos.

Una forma en la cual reducir el acomplamiento es componiendo objetos:

Aquí la aplicación tendrá una ventana, pero ya no tiene que heredar de ella ( no queríamos hacer una versión nueva de la ventana, solo queríamos usarla )

Para reducir aún más el acoplamiento se utilizan niveles de indirección ( o sea que no se use directamente la clase ) en Java esto se logra con interfaces, es por eso que se recomienda programar a la interfaz y no a la clase

Otro ejemplo para que esto quede más claro:

Alto acomplamiento
 

Menor acoplamiento:

Aun menor acoplamiento

Como vez cada versión hace lo mismo pero se va bajando el nivel de dependencia que una clase tiene de otra.

Esto acá se ve muy simple, pero se pone feo cuando se está haciendo por ejemplo un sistema de administración escolar y en algún punto de la aplicación una clase depende mucho de otra cuando quizá no sea necesario:

El código anterior tiene una lista completa de los estudiantes en la clase control escolar, pero si esa lista se necesita en otro mudulo, entonces esta tendría que compartirla.

Una alternativa es tener una clase que remueva la dependencia y nos permita buscar alumnos:

Así se tiene un bajo acoplamiento entre la lista de alumnos y la clase  

Más aún si   es una interfaz, se puede proveer una clase ficticia que devuelva alumnos de prueba o que devuelva alumnos de una base de datos o alumnos de un archivo etc.

En fin... esa es la idea, espero que te sirva.

En cuanto a la cohesión está relacionada con el acoplamiento en el sentido de que si va a haber interacción entre objetos, lo mejor es que esa interacción ( ese acomplamiento ) tenga sentido!

En el ejemplo anterior, tiene sentido que las clases   estén relacionadas porque juntos crean la funcionalidad que buscamos. Esto es tener alta cohesión porque tiene sentido que estas clases estén ahí relacionadas. Lo que no tendría sentido es que ahí mismo y solo por "aprovechar" una funcionalidad existente o algo, hubiera clases para hacer un foro de discusión!. Esa clase debería de ir en otro modulo o otra aplicación.

Espero que esto te sirva.

Acoplamiento:
Es la relacion que tiene una clase con otras clases.
Ejemplo de alto acoplamiento: Cuando muchas clases llaman en particular a una, debido a que contiene una o varias variables a las cuales hay que cambiar el valor, o un metodo o metodos que tambien utilizan mucho estas clases.

Ahora imaginate que por un requerimiento debes de cambiar el algoritmo del metodo que todos usan, pero este cambio no es aplicable a todas las clases, seria un verdadero caos cambiar este algoritmo.

Ejemplo de bajo acoplamiento: En una arquitectura de capas, la parte superior solo puede acceder a la parte media, y la parte media solo accede a la parte baja.

Cohesion:
ES la relacion que tienen los datos y el comportamiento que contiene una clase.
Ejemplo de alta cohesion, una clase que tenga el solamente el comportamiento de un ser humano.
Ejemplo de baja cohesion, una clase que tenga el comportamiento de un perro y una gallina, es decir, la clase puede cacareacar, ladrar, etc.

Ahora, imaginate una factura, si tratamos de contener en una clase los datos y comportamiento relacionados, esta clase debera grabar y consultar la informacion en la base de datos, tendra la interfase de usuario para agregar los datos, hara los calculos necesarios para saber los totales, etc.

Lo que se va a hacer es una clase supergigantesca que va a presentar problemas en cualquier momento.

Al crear una arquitectura y dependiendo de los requerimientos, lo que se necesita hacer, es crear varias clases a las cuales se les asigne a cada una tarea especifica de la factura, por ejemplo una que guarde la informacion, otra que consulte, otra que guarde los datos, etc. repito, depende del deseño y requerimientos esta asignacion de tareas.

muchas gracias por ayudarme .