Buscar este blog

jueves, 24 de febrero de 2011

Introduccion

Introducción
En este tema nos centraremos en el papel que desempeñan las especificaciones de los métodos. Éstas constituyen el eje del trabajo en equipo. No es posible delegar responsabilidad para implementar un método si no existe una especificación. La especificación funciona como un contrato: el implementador es el responsable del cumplimiento del contrato, y un cliente que utilice el método podrá confiar en el contrato. De hecho, veremos que al igual que los contratos reales legales, las especificaciones requieren exigencias por ambas partes: cuando la especificación posee una precondición, el cliente tiene también que afrontar responsabilidades.

Muchos de los peores errores de los programas surgen a causa de malentendidos en el comportamiento de las interfaces. Aunque cada programador tiene en mente las especificaciones, no todos ellos las escriben. Como resultado, cada programador de un equipo posee en mente una especificación distinta. Cuando el programa falla, resulta difícil determinar dónde está el error. Las especificaciones concretas en el código le permiten distribuir la responsabilidad (¡entre los fragmentos del código, no entre el personal!), así como ahorrarle la molestia de tener que darle vueltas a la cabeza para hallar dónde ubicar las correcciones.
Otra de las ventajas de las especificaciones es que ahorran al cliente la tarea de tener que leer el código. Si no está convencido de que la lectura de una especificación es más sencilla que la lectura del código, fíjese en algunas de las especificaciones estándar de Java y compárelas con el código fuente que las implementa. Por ejemplo, Vector, en el paquete java.util, posee una especificación simple, pero su código no lo es en absoluto.

Las especificaciones también benefician al implementador de un método porque le proporcionan libertad para cambiar la implementación sin avisar a los clientes. Las especificaciones pueden aligerar el código. En algunas ocasiones, una especificación débil hace que sea posible conseguir una implementación mucho más eficaz. En concreto, una precondición puede excluir ciertos estados en los que se podría haber invocado a un método y que podrían haber provocado un chequeo costoso que ya no es necesario.
Este tema está relacionado con lo que debatimos en las dos lecciones anteriores sobre el desacoplamiento y las dependencias. En éstas, nos ocupábamos únicamente de si existía una dependencia. Aquí, trataremos de investigar la forma que la dependencia debería adoptar. Al presentar sólo la especificación de un procedimiento, sus clientes se hacen menos dependientes de él y, por tanto, es menos probable que necesiten modificarse cuando el procedimiento cambie.

No hay comentarios:

Publicar un comentario