Patrones de asignación de responsabilidades (GRASP) Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II

Patrones GRASP Recordemos: un patrón es una solución repetitiva a un problema estándar en un contexto dado. También llamados principios. Son utilizados en sistemas orientados a objetos. Permiten asignar responsabilidades a los objetos. El acrónimo fue utilizado por primera vez por Craig Larman, un científico computacional canadiense. Considerado uno de los lideres del desarrollo ágil. Nota: para la realización de los ejemplos trabajaremos con unos de los proyectos del curso ‘joyería’ (el cual contiene muchos errores que tratemos de corregir a medida que avanzamos con cada uno de los patrones).

Patrón Experto Nombre: experto o experto en información. Problema: ¿como asignar responsabilidades a los objetos? Solución: asignar responsabilidad de llevar a cabo una tarea al objeto que tenga la información necesaria para desempeñarla. Pregunta: ¿Qué objeto posee la información necesaria para llevar a cabo el calculo del total de una compra?

Patrón Experto Concentremos en estas clases y pensemos ¿que información necesito para calcular el total de una compra? 1..* Respuesta: se le debe asignar a Compra, ya que el total es la suma de los totales de carrito. Donde esta la cantidad

Patrón Experto Pregunta2: ¿Qué objeto posee la información necesaria para llevar a cabo el calculo del los subtotales de cada compra de cada producto? Pregunta3: ¿Qué objeto posee la información necesaria para obtener la información del precio de un producto? R:/ Carrito R:/ Producto

Patrón Creador Nombre: creador. Problema: ¿Quién debe crear una instancia de A? Solución: asignar la responsabilidad a la clase B de crear una instancia de A si alguna de las siguientes opciones es verdadera (mientras mas opciones verdaderas mejor). B contiene o agrega a A. B registra a A. B utiliza mas estrechamente a A. B contiene los datos de inicialización de A.

Patrón Creador Pregunta: ¿Quién debe crear una instancia de la clase Carrito? Respuesta: se le debe asignar a Compra, ya que la compra esta compuesta por carritos.

Patrón Bajo Acoplamiento El acoplamiento informático indica el nivel de dependencia entre las unidades de software de un sistema informático, es decir, el grado en que una unidad puede funcionar sin recurrir a otras; dos funciones son absolutamente independientes entre sí (el nivel más bajo de acoplamiento) cuando una puede hacer su trabajo completamente sin recurrir a la otra. En este caso se dice que ambas están desacopladas. Nombre: bajo acoplamiento. Se refiere al principio de tratar de mantener al mínimo las relaciones entre las clases o la manera en la que se usen. Problema: ¿Cómo reducir el impacto del cambio y fomentar la reutilización? Solución: asignar la responsabilidad a la clase que contribuya a mantener las relaciones o acoplamientos al mínimo.

Patrón Bajo Acoplamiento Pregunta: ¿A quien se le debería asignar la responsabilidad de crear una valoración? Respuesta: según el bajo acoplamiento a Carrito, para mantener las relaciones y las clases acopladas al mínimo. 1 Valoración

Patrón Controlador Nombre: controlador. Problema: ¿Quién debería ser el responsable de responder a los eventos de la interfaz grafica? Solución: asignar la responsabilidad a un objeto representativo “fachada”. O asignar la responsabilidad a un objeto representativo del escenario del caso de uso (en el MVC se asigna a un controlador).

Respuesta: un controlador. Patrón Controlador Problema: al dar clic en enviar, ¿Quién debería capturar la solicitud? Respuesta: un controlador. modificarEstado()

Patrón Alta Cohesión Cohesión: La cohesión es la medida en la que un componente se dedica a realizar solo la tarea para la cual fue creado, delegando las tareas complementarias a otros componentes. (Una clase debe de hacer lo que respecta a su entidad, y tratar de no hacer acciones que involucren a otra clase ó entidad). Nombre: alta cohesión. Problema: ¿Cómo mantener las clases enfocadas en sus tareas propias y manejables? Solución: asignar responsabilidades basándose en el principio de la cohesión.

Patrón Alta Cohesión Pregunta: ¿Quién debería registrar y eliminar comentarios? Respuesta: La clase comentario ya que es ella quien maneja la información de los datos de un comentario. Como veremos después, quizás sea mejor que lo realice una clase de FABRICACIÓN PURA.

Patrón Fabricación Pura Nombre: fabricación pura. Problema: ¿como asignar responsabilidades cuando la alta cohesión y el bajo acoplamiento se ven comprometidos? Solución: asigne un conjunto cohesivo de responsabilidades a una clase artificial (la cual no representa ningún concepto del dominio del problema). Ejemplos: gestor de base de datos, manejo de variables del sistema, .

Patrón Polimorfismo Nombre: polimorfismo. Problema: ¿como manejar el comportamiento basado en el tipo de un objeto, pero sin utilizar un if o un switche? Solución: asignar una operación polimórfica a los tipos para los que varían los casos. Ejemplo: triangulo, cuadrado y rectángulo. Se pide contar con una función para calcular el área de cada uno.

Patrón Polimorfismo Solución en C++

Patrón Indirección Nombre: indirección. Problema: ¿Dónde asignar responsabilidades para evitar/reducir el acoplamiento y mejorar la reutilización? Solución: asigne la responsabilidad a objetos intermediarios para que el acoplamiento sea indirecto. Ejemplo: MVC, el controlador que es intermediario entre la vista y el modelo.

Falta relación usuario - comentario 1..* Modificadores deben ser privados o protegidos PrecioTotal va en compra y falta cantidad en carrito - Comprarproducto en usuario? pagado? Significa el total o significa que hay un sistema luego para abonar? Comprar en carrito o en compra? Stock y vendido cual es la diferencia?

Bibliografía Larman, C. (2002). Applying UML and Patters: An introduction to Object-oriented analysis and design and the Unified Process. Learning UML 2.0 O’Reilly. 2006. Software Modeling & desing. UML, use cases, patterns, & software architectures. Hassan Gomma. 2011. Ingenieria del software. 7th edición. Ian Somerville. 2005. UML y patrones. Craig Larman. 1999. Ingeniería del software. Un enfoque practico 5ta edición. Roger S. Pressman. 2002. Use Case Driven Object Modeling with UML, Theory and Practice. Doug Rosenberg. 2007.