1.3 Plantilla de un patrón de diseño
La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:
· Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
· Clasificación del patrón: creacional, estructural o de comportamiento.
· Intención: ¿Qué problema pretende resolver el patrón?
· También conocido como: Otros nombres de uso común para el patrón.
· Motivación: Escenario de ejemplo para la aplicación del patrón.
· Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
· Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.
· Participantes: Enumeración y descripción de las entidades abstractas (y sus roles) que participan en el patrón.
· Colaboraciones: Explicación de las interrelaciones que se dan entre los participantes.
· Consecuencias: Consecuencias positivas y negativas en el diseño derivadas de la aplicación del patrón.
· Implementación: Técnicas o comentarios oportunos de cara a la implementación del patrón.
· Código de ejemplo: Código fuente ejemplo de implementación del patrón.
· Usos conocidos: Ejemplos de sistemas reales que usan el patrón.
· Patrones relacionados: Referencias cruzadas con otros patrones.
Clasificación de Patrones
Hay varios tipos de patrones, los mas comunes son de arquitectura de diseño y de análisis
Con esta simple tabla podemos identificar algunos de los patrones de diseño más comunes y utilizados a la hora de diseñar
3.4 MODELO-VISTA-CONTROLADOR
Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos. El patrón de llamada y retorno MVC (según CMU), se ve frecuentemente en aplicaciones web, donde la vista es la página HTML y el código que provee de datos dinámicos a la página. El modelo es el Sistema de Gestión de Base de Datos y la Lógica de negocio, y el controlador es el responsable de recibir los eventos de entrada desde la vista.
Elementos del patrón:
Modelo: datos y reglas de negocio
Vista: muestra la información del modelo al usuario
Controlador: gestiona las entradas del usuario
-El modelo es el responsable de:
· Acceder a la capa de almacenamiento de datos. Lo ideal es que el modelo sea independiente del sistema de almacenamiento.
· Define las reglas de negocio (la funcionalidad del sistema). Un ejemplo de regla puede ser: "Si la mercancía pedida no está en el almacén, consultar el tiempo de entrega estándar del proveedor".
· Lleva un registro de las vistas y controladores del sistema.
· Si estamos ante un modelo activo, notificará a las vistas los cambios que en los datos pueda producir un agente externo (por ejemplo, un fichero bath que actualiza los datos, un temporizador que desencadena una inserción, etc).
-El controlador es responsable de:
· Recibe los eventos de entrada (un clic, un cambio en un campo de texto, etc.).
· Contiene reglas de gestión de eventos, del tipo "SI Evento Z, entonces Acción W". Estas acciones pueden suponer peticiones al modelo o a las vistas. Una de estas peticiones a las vistas puede ser una llamada al método "Actualizar()". Una petición al modelo puede ser "Obtener_tiempo_de_entrega( nueva_orden_de_venta )".
-Las vistas son responsables de:
·Recibir datos del modelo y los muestra al usuario.
· Tienen un registro de su controlador asociado (normalmente porque además lo instancia).
· Pueden dar el servicio de "Actualización()", para que sea invocado por el controlador o por el modelo (cuando es un modelo activo que informa de los cambios en los datos producidos por otros agentes)
El usuario interactúa con la interfaz de usuario de alguna forma (por ejemplo, el usuario pulsa un botón, enlace, etc.)
1 El controlador recibe (por parte de los objetos de la interfaz-vista) la notificación de la acción solicitada por el usuario. El controlador gestiona el evento que llega, frecuentemente a través de un gestor de eventos (handler) o callback.
2 El controlador accede al modelo, actualizándolo, posiblemente modificándolo de forma adecuada a la acción solicitada por el usuario (por ejemplo, el controlador actualiza el carro de la compra del usuario). Los controladores complejos están a menudo estructurados usando un patrón de comando que encapsula las acciones y simplifica su extensión.
3 El controlador delega a los objetos de la vista la tarea de desplegar la interfaz de usuario. La vista obtiene sus datos del modelo para generar la interfaz apropiada para el usuario donde se reflejan los cambios en el modelo (por ejemplo, produce un listado del contenido del carro de la compra). El modelo no debe tener conocimiento directo sobre la vista. Sin embargo, se podría utilizar el patrón Observador para proveer cierta indirección entre el modelo y la vista, permitiendo al modelo notificar a los interesados de cualquier cambio. Un objeto vista puede registrarse con el modelo y esperar a los cambios, pero aun así el modelo en sí mismo sigue sin saber nada de la vista. El controlador no pasa objetos de dominio (el modelo) a la vista aunque puede dar la orden a la vista para que se actualice. Nota: En algunas implementaciones la vista no tiene acceso directo al modelo, dejando que el controlador envíe los datos del modelo a la vista.
4 La interfaz de usuario espera nuevas interacciones del usuario, comenzando el ciclo nuevamente.
Bibliografía
Ingeniería de la web y patrones de diseño Mª Paloma Diaz
Susana Montero
Ignacio Aedo
UML y patrones 1 y 2ª edicion Craig Larman más usados
Patrones de diseño Richard Helm
Ralph Johnson
Jhon Vlissides
Apuntes de la asignatura
No hay comentarios:
Publicar un comentario