|
1.9.2. Fase 1: ¿Qué estamos haciendo? |
|
1.9.4. Fase 3: Construir el núcleo |
|
En esta fase debe aparecer un diseño que describa qué clases hay y cómo interactúan. Una técnica excelente para determinar clases es la tarjeta Clase-Responsabilidad-Colaboración (Class-Responsibility-Collaboration) o CRC. Parte del valor de esta herramienta es que es baja-tecnología: empieza con una colección de 3 a 5 tarjeta en blanco, y se escribe sobre ellas. Cada tarjeta representa una única clase, y en ella se escribe:
El nombre de la clase. Es importante que el nombre refleje la esencia de lo que hace la clase, así todo tiene sentido con un simple vistazo.
Las «responsabilidades» de la clase: qué debe hacer. Típicamente se puede resumir por la misma declaración de las funciones miembro o métodos (ya que esos nombres pueden ser descritos en un buen diseño), pero no descarte otras notas. Si necesita hacer una selección previa, mire el problema desde un punto de vista de programador perezoso: ¿Qué objetos quiere que aparezcan por arte de magia para resolver su problema?
Las «colaboraciones» de la clase: ¿qué otras
clases interactúan con ésta? «Interacción» es
un término amplio a propósito; puede significar agregación o
simplemente que algún otro objeto que lleva a cabo servicios
para un objeto de la clase. Las colaboraciones deberían
considerar también la audiencia para esta clase. Por
ejemplo, si crea una clase Petardo,
¿quién va a observarlo, un Químico o
un Espectador? El primero puede
querer saber qué componentes químicos se han usado en su
construcción, y el último responderá a los colores y figuras
que aparezcan cuando explote.
Puede creer que las fichas pueden ser más grandes por toda la información que pondrá en ellas, pero son pequeñas a propósito, no sólo para que las clases se mantengan pequeñas también para evitar tener que manejar demasiados detalles demasiado pronto. Si no puede apuntar todo lo que necesita saber sobre una clase en una ficha pequeña, la clase es demasiado compleja (a está poniendo demasiados detalles, o debería crear más de una clase). La clase ideal se entiende con un vistazo. La idea de las fichas CRC es ayudarle a realizar un acercamiento con un primer corte del diseño y que pueda obtener una visión global y después refinar su diseño.
Uno de los mayores beneficios de las tarjetas CRC es la comunicación. Se hace mejor en tiempo-real, en grupo, sin computadores. Cada persona es responsable de varias clases (que al principio no tienen nombres ni otra información). Haga una simulación en vivo resolviendo un escenario cada vez, decidiendo qué mensajes envía a varios objetos para satisfacer las necesidades de cada escenario. Al pasar por este proceso, descubrirá las clases que necesita con sus responsabilidades y colaboraciones, rellene las tarjetas del mismo modo. Cuando haya pasado por todos los casos de uso, debería disponer de un primer corte bastante completo su diseño.
Antes de empezar a usar fichas CRC, las mayoría de las experiencias de consultoría exitosas las tuve cuando me enfrentaba con un diseño inicial complicado estando al frente de un equipo, que no había construido un proyecto POO antes, y dibujando objetos en un pizarra blanca. Hablábamos sobre cómo los objetos deberían comunicarse unos con otros, y borrábamos algunos de ellos para reemplazarlos por otros objetos. Efectivamente, yo gestionaba todas las«tarjetas CRC» en la pizarra. Realmente, el equipo (que conocía lo que el proyecto se suponía tenía que hacer) creó el diseño; ellos «poseían» el diseño en lugar de tener que dárselo. Todo lo que yo hacía era guiar el proceso haciendo las preguntas correctas, poniendo a prueba los suposiciones, y llevando la retroalimentación del equipo para modificar esas suposiciones. La verdadera belleza del proceso era que el equipo aprendía cómo hacer diseños orientado a objetos no revisando ejemplos abstractos, sino trabajando sobre un diseño que era más interesante para ellos en ese momento: los suyos.
Una vez que tenga con una serie de tarjetas CRC, quizá quiera crear una descripción más formal de su diseño usando UML [22]. No necesita usar UML, pero puede servirle de ayuda, especialmente si quiere poner un diagrama en la pared para que todo el mundo lo tenga en cuenta, lo cual es una buena idea. Una alternativa a UML es una descripción textual de los objetos y sus interfaces, o, dependiendo de su lenguaje de programación, el propio código [23].
UML también proporciona una notación de diagramas adicional para describir el modelo dinámico de su sistema. Eso es útil en situaciones en las que las transiciones de estado de un sistema o subsistema son bastante más dominantes de lo que necesitan sus propios diagramas (como en un sistema de control). También puede necesitar describir las estructuras de datos, para sistemas o subsistemas en los que los propios datos son un factor dominante (como una base de datos).
Sabrá qué está haciendo con la fase 2 cuando haya descrito los objetos y sus interfaces. Bien, en muchos de ellos hay algunos que no se pueden conocer hasta la fase 3. Pero está bien. Todo lo que le preocupa es que eventualmente descubra todo sobre sus objetos. Es bueno descubrirlos pronto pero la POO proporciona suficiente estructura de modo que no es grave si los descubre más tarde. De hecho, el diseño de un objeto suele ocurrir en cinco etapas, durante todo el proceso de desarrollo del programa.
La vida del diseño de un objeto no se limita a la escritura del programa. En cambio, el diseño de un objeto ocurre en una secuencia de etapas. Es útil tener esta perspectiva porque no debería esperar alcanzar la perfección enseguida; en lugar de eso, se dará cuenta que entender lo que hace un objeto y a qué se debería que ocurre con el tiempo. Esta vista también se aplica al diseño de varios tipos de programas; el patrón para un tipo particular de programas surge a fuerza de pelearse una y otra vez con ese problema (los Patrones de Diseño se desarrollan en el Volumen 2). Los objetos, también, tienen sus patrones que surgen del entendimiento, uso y reutilización.
Descubrimiento de objetos. Esta etapa ocurre durante el análisis inicial de un programa. Los objetos pueden descubrirse viendo los factores externos y los límites, duplicación de elementos en el sistema, y las unidades conceptuales más pequeñas. Algunos objetos son obvios si se dispone de un conjunto de librerías de clases. Las partes comunes entre clases pueden sugerir clases base y herencia que pueden aparecer pronto, o más tarde en el proceso de diseño.
Montaje de objetos. Si está construyendo un objeto descubrirá la necesidad de nuevos miembros que no aparecen durante la fase de descubrimiento. Las necesidades internas del objeto pueden requerir otras clases que le den soporte.
Construcción del sistema. Una vez más, pueden aparecer más requisitos para un objeto a lo largo de esta etapa. Conforme aprende, evoluciona sus objetos. La necesidad de comunicación e interconexión con otros objetos en el sistema puede cambiar las necesidades de sus clases o requerir clases nuevas. Por ejemplo, puede descubrir la necesidad de clases utilería o ayudantes (helper), como una lista enlazada, que contienen o no una pequeña información de estado y que simplemente ayudan a la función de otras clases.
Extensión del sistema. Cuando añada nuevas características a un sistema puede descubrir que su diseño previo no soportaba extensiones sencillas del sistema. Con esta nueva información, puede reestructurar partes del sistema, posiblemente añadiendo nuevas clases o jerarquía de clases.
Reutilización de objetos. Esta es la verdadera prueba de estrés para una clase. Si alguien intenta reutilizarla en una situación completamente nueva, probablemente descubrirá algunos defectos. Si cambia una clase para adaptarla a nuevos programas, los principios generales de la clase se verán más claros, hasta que consiga un tipo verdaderamente reutilizable. Sin embargo, no espere que muchos objetos del diseño de un sistema sean reutilizables -es perfectamente aceptable que la mayor parte de los objetos sean específicos para el sistema. Los tipos reutilizables tienden a ser menos comunes, y deben resolver problemas más generales para ser reutilizables.
Estas etapas sugieren algunas directrices cuando se piensa sobre el desarrollo de clases:
Permita que un problema específico dé lugar a una clase, después deje que la clase crezca y madure durante la solución de otros problemas.
Recuerde, descubrir las clases que necesita (y sus interfaces) supone la mayor parte del diseño del sistema. Si ya tenía esas clases, será un proyecto fácil.
No se esfuerce por saber todo desde el principio; aprenda conforme avanza. Ocurrirá así de todos modos.
Comience a programar; consiga tener algo funcionando para poder aprobar o desaprobar su diseño. No tenga miedo a que acabe haciendo código procedural espagueti -las clases dividen el problema y ayudan a controlar la anarquía y la entropía. Las clases malas no estropean las buenas.
Manténgalo simple. Pequeños objetos claros con utilidades obvias son mejores que grandes interfaces complicadas. Cuando aparezcan los puntos de decisión, aplique el principio de la Navaja de Occam: Considere las alternativas y elija la más simple, porque las clases simples casi siempre son mejores. Empiece con clases pequeñas y sencillas, y podrá ampliar la interfaz cuando la entienda mejor, pero cuando esto ocurra, será difícil eliminar elementos de la clase.
[22] Para novatos, recomiendo el mencionado UML Distilled.
[23] Python (www.python.org) suele utilizarse como «pseudocódigo ejecutable».
