"El nombre del patrón comunica la esencia del patrón de manera sucinta. Un buen nombre es vital, ya que puede llegar a ser parte de su vocabulario de diseño..." [Gamma95:6]Pensemos en lo que significa abstraer un concepto.
Pues primero tenemos que tener al menos una idea de lo que significa o de las repercusiones que tiene aquello que queremos describir. Uno no fabrica patrones porque está de buen humor y tiene ganas de hacer patrones, los hace porque los conoce o porque ha detectado la necesidad de un tipo particular de comportamiento que desconocía, pero que puede descubrir poco a poco conforme evoluciona su entendimiento de ese comportamiento.
Luego, el patrón es un gran arma para decir de manera absoluta lo que hicimos (crear documentación técnica de verdad), pero también es una mejor arma de comunicación. La gente que trate de entender nuestro trabajo dentro de diez años tendrá a la mano un texto que le dirá exactamente lo que es nuestro trabajo en términos abstractos. Sin embargo hay algo mucho mejor que esto.
El día de mañana, cuando fabriquemos nuevos productos, podremos revisar nuestro catálogo de patrones para ver si el comportamiento que estamos buscando ya había sido creado por alguien en el pasado. Y ¿cómo buscamos ágilmente en un catálogo de patrones?
Hay dos factores importantes:
1) Un nombre que indique claramente lo que estamos describiendo.
2) Una clasificación que nos enseñe la orientación
de lo que describimos.
Veamos algunos nombres de patrones y sus descripciones:
Estos patrones poseen nombres muy claros. Podemos incluírlos, si es que ya no los tenemos, dentro de nuestro vocabulario. En el caso del patrón comando, es ya común hablar de él cuando le enviamos una instrucción a un programa.Observador
Intención
Define una dependencia uno a muchos entre objetos de tal manera que cuando un objeto cambia de estado, todos sus dependientes son notificados y actualizados de manera automática.Comando
Intención
Encapsula una solicitud como un objeto, permitiéndole al usuario parametrizar clientes con diferentes solicitudes, encolar o registrar solicitudes, y soporta operaciones anulables.
Escribimos comandos en un intérprete de SQL, enviamos comandos cada vez que presionamos un botón o que vamos hacia una opción del menú, llevamos a cabo un comando cuando cambiamos la marcha en el vehículo o cuando encendemos la luz, etc.
Podemos cambiar radicalmente el punto de vista sobre el comando que pretendemos llevar a cabo (por eso puse el ejemplo de la marcha del vehículo y del acto de encender una luz), pero en el fondo son lo mismo que presionar un botón en la pantalla o buscar una opción en un menú. Entonces, el nombre de Comando está muy bien especificado.
En el caso del Observador, es un patrón especial que también utilizamos pero que no somos muy conscientes de ello. Cuando tenemos una hoja electrónica con datos numéricos y creamos un gráfico, estamos creando un Observador. Esto, por cuanto si cambiamos los datos, el diagrama se da cuenta del cambio y es actualizado. También tenemos un Observador cuando existe algún Sistema que monitoree algo y se da cuenta de que ese algo ha cambiado (por ejemplo un sismógrafo), o cuando utilizamos el chat para comunicarnos con alguna persona.
Es el trasfondo de la idea de que alguien observa y cuando se da cuenta de que lo que observa cambia, reacciona. El nombre de Observador también es perfecto.
Y siempre que tengamos que realizar algo y consideremos conveniente que en alguna parte de este algo se presente un tipo de comportamiento semejante al de un Comando o al de un Observador, pues lo mencionamos y todo el mundo sabrá de lo que se está hablando, incluyendo lo bueno y lo malo que pueda tener esto, ya que los patrones están escritos.
La clasificación será el tema del próximo capítulo..