 |
| Imagen: Autorretrato con Sombrero de Paul Gauguin |
Desde los primeros cursos de orientación a objetos de la universidad he escuchado que al programar se debe procurar siempre
"niveles bajos de acoplamiento y altos de cohesión". Recién ahora que estoy ojeando
The Pragmatic Programmer de Andrew Hunt y David Thomas el tema del acoplamiento me ha quedado claro y quería compartir con ustedes mis hallazgos.
Es más fácil entender este concepto si vemos un programa que no lo aplica. El libro propone este ejemplo:
public void plotDate(Date aDate, Selection aSelection) {
TimeZone tz = aSelection.getRecorder().getLocation().getTimeZone();
...
}
La clase que contiene al método
plotDate está altamente acoplada, dado que su estructura actual depende de otras tres clases:
Selection,
Recorder y
Location. Esto nos pone en una situación delicada, dado que un cambio en cualquiera de esas tres clases tendría impacto en nuestro programa. Por ejemplo, si
Location hace que el método
getTimeZone sea privado, nuestro método tendría que redefinirse, y lo mismo pasaría con modificaciones a cualquiera de las otras clases dependientes. Es por eso que se recomienda mantener los niveles de acoplamiento mínimos (es decir, depender del mínimo número de clases) para evitar que las ocurrencias del resto deshagan nuestro trabajo. Si bajamos el nivel de acoplamiento de clase de arriba, nos quedaría algo así:
public void plotDate(Date aDate, TimeZone aTz) {
...
}
Ahora nuestro método espera que le llegue una instacia de
TimeZone como parámetro y ya no la obtiene desde un objeto Selection. De este modo hemos reducido las dependencias de tres a una clase (sólamente
TimeZone ), siendo responsabilidad de la clase cliente la obtención de la instancia de TimeZone que necesitamos. Esta clase cliente nos puede invocar de esta manera:
plotDate(someDate, someSelection.getTimeZone());
El libro menciona que los síntomas clásicos de un programa altamente acoplado son que los cambios más simples impactan en componentes que no deberían, y que los programadores se resisten a darle mantenimiento al sistema por miedo a echar a perder algo.
Descrito al problema, ahora toca describir la solución.
La
ley de Deméter -inventada en 1987 en la Northeastern University - tiene como objetivo el minimizar las dependencias entre las clases de un programa dado, previniendo el acceso a objetos externos para consumir sus métodos. En resumen, la ley establece lo siguiente:
Cualquier método de un objeto debe invocar solamente a los siguientes métodos:
- Sus propios métodos
- Los métodos de los objetos que ha recibido como parámetros
- Los métodos de los objetos que posee como atributos
- Los métodos de los objetos declarados como variables locales
Con esto aseguramos el mínimo de dependencias posibles. Los dejo con una imagen extraída del libro que ilustra el concepto:
 |
| Imagen tomada de The Pragmatic Programmer de Andrew Hunt y David Thomas |
Hasta otra!
