Otras revisiones

Ya hemos señalado repetidamente que el objetivo fundamental de la orientación al objeto es la reutilización de los objetos. Cualquier medida de la calidad en relación con la modelización del dominio o con el análisis, el diseño y la programación orientadas a objetos, debe partir de este objetivo básico.

Desde el punto de vista de las clases definidas, debemos tener en cuenta:

• El número de clases. Un modelo con un gran número de clases puede dificultar la comprensión global del sistema pero facilita la reutilización.

• La nomenclatura utilizada. Si tenemos un cuenta que las librerías de objetos pueden llegar a tener miles de componentes, queda claro el papel fundamental que una buena nomenclatura tiene en relación con la reutilización.

• El número de clases abstractas y sus relaciones. En general, es preferible una estructura profunda, con muchas clases intermedias que faciliten la reutilización, que una estructura plana. Las relaciones verticales permiten captar y expresar las diferencias y puntos comunes entre los objetos. En cambio, las estructuras planas suelen aportar pocos atributos y servicios que puedan ser reutilizables, y suelen generar una fuerte redundancia.

• La información contenida en las clases. Debemos evitar un número excesivo de atributos. De todas formas, este criterio es relativo; no es lo mismo una clase básica que una vista o que un objeto controlador. También el número de servicios debería limitarse. Coad nos recomienda un máximo de siete servicios visibles por objeto. También los acoplamientos entre objetos deberían limitarse. En general, una norma que hay que seguir es favorecer la simplicidad de los objetos y de las relaciones.

Respecto a los servicios, podemos describir una serie de criterios:

• Servicios coherentes, pequeños y consistentes. En general debemos intentar que cada servicio cubra una sola función. El tamaño de los servicios debe ser pequeño. Una herramienta CASE denominada OBJECTTOOL tiene un tamaño medio de 5,5 líneas de código por servicio. Los servicios deben ser consistentes en cuanto a funcionalidad, nomenclatura y signatura, entre los diferentes objetos, para implementar funcionalidades similares.

• Los protocolos de comunicación entre objetos deben ser tan sencillos como sea posible. Se recomienda limitar a tres el número de parámetros.

Respecto a la organización general del modelo, también podemos proponer una serie de criterios:

• Conviene favorecer la utilización de una nomenclatura consistente entre las clases, así como la definición de unos servicios generales comunes a todas. La utilización de estándares para atributos y servicios de las clases puede ser una buena técnica.

• El número de subsistemas que se detecten entre las clases es importante. Un sistema con muchos subsistemas y pocas clases aisladas suele ser mejor para encapsular las funcionalidades de la aplicación.

• Hay que favorecer la creación de frameworks.

• Hay que favorecer la utilización de patrones.