Pensar en C++ (Volumen 1) - Grupo ARCO

✐
✐
✐
“Volumen1” — 2012/1/12 — 13:52 — page 23 — #61
✐
1.9. Análisis y diseño
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 12 . 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 13 .
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.
Las cinco etapas del diseño de objetos
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.
1. 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.
12 Para novatos, recomiendo el mencionado UML Distilled.
13 Python (www.python.org) suele utilizarse como «pseudocódigo ejecutable».
23
✐
✐
✐
✐