4.2 Diseño de Objetos.

Contratos

Un contrato es una mecanismo de diseño para agrupar las responsabilidades de una clase que tienen relaciones entre sí, sirviendo como indicadores de los diversos servicios provistos por cada clase.

El contrato es un elemento de abstracción adicional en el manejo de la complejidad del diseño, ayudando en la asignación y reasignación de responsabilidades, donde grupos de responsabilidades funcionalmente relacionadas deben ser comunes a un mismo contrato. A diferencia de los contratos, las responsabilidades representan una visión más detallada de los servicios provistos por la clase. En general, una clase puede apoyar uno o más contratos, aunque a menudo una clase con varias responsabilidades apoya un sólo contrato.

Un contrato entre dos clases representa una lista de servicios que una instancia de una clase puede solicitar de una instancia de otra clase. Todos los servicios especificados en un contrato particular son la responsabilidad del servidor para ese contrato. Las responsabilidades correspondientes al contrato deben ser ofrecidas públicamente. Por lo tanto, para un mejor manejo de la complejidad del sistema, se debe posponer la definición de los aspectos privados de una clase y concentrarse inicialmente en las responsabilidades públicas.

En general, un contrato entre un cliente y un servidor no específica cómo se hacen las cosas, solo qué se hace. Los contratos especifican quien colabora con quien, y qué se espera de la colaboración. El contrato cliente-servidor divide los objetos en dos categoría aquellos que proveen servicios (servidores), y aquellos que piden servicios (clientes). De tal manera, un contrato es una lista de pedidos que le hace un cliente a un servidor. Ambos deben satisfacer el contrato, el cliente haciendo sólo los pedidos que el contrato especifica, y el servidor respondiendo apropiadamente a estos pedidos.

Si una clase define un contrato que tiene relativamente poco en común con el resto de los contratos definidos por esa clase, este contrato debe ser movido a una clase diferente, usualmente una superclase o subclase. De tal manera, se puede refinar las jerarquías de clases maximizando la cohesión de contratos para cada clase. Maximizando la cohesión tenderá a minimizar el número de contratos apoyados por cada clase. Esto es algo deseable, ya que cuanto menos contratos existan, se logrará un sistema más fácil de comprender. En general, la mejor manera de reducir el número de contratos es buscar responsabilidades similares que puedan generalizarse. Esto también resultará en jerarquías de clases más extensibles.

Un buen diseño hace un balance entre clases pequeñas con pocos contratos, fáciles de comprender y reutilizar, con un número reducido de clases más complejas cuyas relaciones entre ellas se puede comprender mas fácilmente. Una técnica para definir contratos es comenzar definiendo primero los contratos de las clases más arriba en las jerarquías. Posteriormente, se definen nuevos contratos para las subclases que agregan nueva funcionalidad. Se debe examinar las responsabilidades para cada subclase y determinar si estas representan nueva funcionalidad o si son simplemente maneras específicas de expresar responsabilidades heredadas, en cuyo caso serían parte del contrato heredado.