Curso en Reutilización de Software

Taller de aplicación de patrones.

UNAB
Omar Gómez
22/01/07

Problema #1 ( Aplicar Factory Method )

Existe una infinidad de protocolos de conexión a servidores de correo electrónico ( POP, IMAP, MS
Exchange, etc. ), y uno de ellos debe especificarse cuando se crea una nueva cuenta de correo en la
aplicación. La funcionalidad de manejo de correo es transparente al protocolo utilizado, es decir, los
mensajes son creados y enviados de la misma forma, independientemente del protocolo especificado
para la cuenta.
¿Cuál debe ser el diseño de clases que permite a la aplicación poder manejar diferentes protocolos de
correo electrónico sin que sea necesario cambiar el diseño del módulo que soporta la funcionalidad de
manejo de correo?
Reto:
● Transparencia en el protocolo utilizado.
● Posibilidad de adicionar nuevos protocolos sin afectar las clases no cambiantes del diseño.
Diálogo de configuración de cuentas. El campo Tipo de servidor permite
especificar el protocolo para la recepción de correos
 Problema #2 ( Builder )
La aplicación permitirá que los elementos de la agenda ( los contactos ), el calendario ( las citas ) y el
memo ( las notas ) puedan ser enviados por correo electrónico. Para ello la interfaz de cada uno de
estos elementos habilitará el uso de un botón “enviar por correo...” que abrirá una ventana de correo
donde solo se entrará el destinatario y el cuerpo del mensaje, ya que el asunto y el adjunto serán
creados automáticamente a partir del elemento
¿ Cuál debe ser el diseño para que la lógica asociada al botón permita crear el asunto y el cuerpo del
mensaje para cualquier tipo de elemento ?
Reto:
● Simplifique el diseño sabiendo que el correo electrónico a construir siempre tiene las misma
partes ( destinatario, asunto, cuerpo )
● Al mismo tiempo permita que el diseño sea extensible para nuevos tipos de elementos en el
cliente ( por ejemplo tareas en un cronograma )

Correo creado automáticamente a partir de una entrada en los contactos.

Nótese el campo Asunto y el adjunto adicionados automáticamente.
 Problema #3 ( Singleton )
El usuario del cliente de correo puede enviar cualquier mensaje a una papelera especial para mensajes
eliminados. Existe sola una carpeta con esta función, y debe ser usada una vez al tiempo por las demás
partes del programa.
¿Cómo diseñaría la clase que maneja la funcionalidad de papelera de reciclaje de tal manera que
pueda existir una sola instancia en tiempo de ejecución?
Reto:
● Simplifique el diseño y trate de utilizar el menor número de clases y objetos posibles

Lista de carpetas. Sólo una de las carpetas puede funcionar como papelera de
reciclaje.
 Problema #4 ( Composite )
Las tareas definibles en la aplicación tienen un nombre, una descripción y un tiempo presupuestado
para ser completadas. También es posible definir tareas compuestas, en la que una tarea padre agrupa
subtareas; en este caso no es necesario que el usuario defina el tiempo de la tarea padre ya que este es
la suma del tiempo de sus subtareas.
Existe una lógica de presentación que muestra la lista de tareas pendientes y su tiempo presupuestado,
¿ Cual diseño de clases facilita que esta lógica mostrar el atributo de “tiempo presupuestado” sin
importar si se trata de una tarea simple o una compuesta ?
Reto: Simplicidad en el diseño. Hacer que la dependencia de la presentación sobre la abstracción que
representa las tareas sea simple y ( en los posible ) sólo se de sobre una sola clase.

Lista de tareas. La columna % Terminado muestra el porcentaje que ha sido

completado de la tarea.
 Problema #5 ( Observer )
El módulo de calendario de la aplicación es visualmente muy sofisticado, tienen varias áreas:
● Una lista de tareas registradas
● Los detalles de la tarea actualmente seleccionada en la lista, donde los campos pueden ser
modificados si se quiere
● Una vista configurable del calendario, el usuario puede escoger entre varias opciones:
● Vista del día y vista compacta del mes
● Vista de la semana y vista compacta del mes
● Vista detallada del mes
Las vistas del calendario resaltan visualmente con un color, el rango de tiempo de la cita actualmente
seleccionada de la lista, y si este rango cambia ( el usuario lo edita ), las vistas reflejan
automáticamente el cambio.
Diseñe un conjunto de clases que represente las abstracciones de este escenario, y que permita a las
vistas del calendario resaltar la franja de tiempo que la tarea que está actualmente seleccionada.
Reto:
● Mantenibilidad: Optimizar el diseño de tal forma que las clases del calendario sean
independientes de las clases de las tareas, y aun así permitirles la interacción deseada
anteriormente.

Calendario. Observe la vista semanal a la izquierda, por meses en la parte

superior, y la lista de tareas debajo de esta. En el extremo derecho de la barra
superior se encuentran los botones que permiten cambiar esta configuración.