Patrones grasp controlador

GRASP-
1 - Experto en Información

P- ¿Un principio general del diseño De objetos y la asignación de responsabilidades?

R-
Asignar Responsabilidades al experto de La información, es decir, a la clase Que tiene la información necesaria para llevar la tarea a cabo.

Cons

Encapsulamiento de la información y, por ende, el bajo Acoplamiento.

El comportamiento distribuido entre las clases, es decir, clases más Cohesivas.

Ej-

En La aplicación punto de venta, alguna Clase necesita conocer el gran total de la venta.

Se Plantea esta pregunta: ¿Quién es el Responsable de conocer el gran total de la venta?

Para calcular el total hay que conocer todas las instancias
VentasLineadeProducto de una venta y La suma de sus subtotales.
Y esto conoce únicamente La instancia Venta;
Desde el punto De vista del Experto, Venta es la clase correcta para asumir esta Responsabilidad; es el experto en información.

Cont-
En algunas ocasiones no es una guía Deseable sobre todo por problemas de Cohesión, acoplamiento y duplicación de código.
(Si venta debe Ser almacenada en una base de datos, el Experto sugiere a Venta como Responsable, pues contiene mucha de la información a almacenar

Patr-
Bajo Acoplamiento y Alta Cohesión.

GRASP-
2 - Creador

P-¿Quién debe ser responsable en la creación De una nueva instancia de una clase?

R- Una clase B tiene la responsabilidad para crear Una instancia de la clase A (si cumple alguna):

B agrega objetos de A.

B contiene objetos de A.

B almacena objetos de A.

B usa objetos de A.

B tiene los datos necesarios para inicializar A A cuando este es creado

Cons-

Soporta el bajo acoplamiento, es decir, este no se Incrementa.

Ej

En la aplicación PDV, ¿quién debería crear una LineaDeVenta?
Venta de hecho contiene (agrega) muchos objetos de LIneaDeVenta, debe tener, por lo tanto, la responsabilidad de la Creación de instancias de esta clase y por lo tanto contener un método crearLineaDeVenta.

Cont-
A menudo la creación de instancias es una tarea Compleja, en estos casos es aconsejable delegar la creación a una clase Auxiliar denominada Factoría.

Patr-
Bajo Acoplamiento Y Factoría.

GRASP-
3 - Bajo Acoplamiento

P- ¿Cómo dar soporte a una dependencia escasa Y a un aumento de la reutilización?

R- Asignar Responsabilidades de tal manera que el acoplamiento sea el menor posible

Cons

Mejor compresión de las clases aisladas.

Facilitan la reutilización de código.

No afectan los cambios en otros Componentes.

Ej-

Suponiendo Que se necesita crear una instancia Pago y asociarla a Venta. ¿Qué clase se Encargará de hacer esto?

Puesto que una Instancia TPDV registra un Pago, el patrón Creador indica que TPDV es un buen Candidato para producir el Pago. La instancia TPDV podría entonces enviarle a Venta el mensaje agregarPago, transmitiendo al mismo tiempo el nuevo Pago como Parámetro.

Patr-

Variaciones Protegidas

GRASP-
4 - Alta Cohesión

P- ¿Cómo mantener la complejidad dentro de Los límites manejables?

R- Asignar una responsabilidad de modo que La cohesión siga siendo alta

Cons

Se incrementa la claridad y facilita la Comprensión, se simplifica el mantenimiento.

Implica casi siempre bajo acoplamiento, Incrementando la reutilización.

Ej-
Este ejemplo es una contradicción, es Decir, el ejemplo va en contra del patrón de Alta Cohesión.

Patr-

Bajo Acoplamiento

GRASP-
5 - Controlador

P- ¿Quién debería encargarse de atender un Evento del sistema?

R-
Asignar la responsabilidad del manejo de Un mensaje de los eventos de un sistema a una clase que represente una de las Siguientes opciones:

· El sistema global: controlador de fachada.

·La empresa u organización global: Controlador de fachada.

· Algo en el mundo real que es activo y Que pueda participar en la tarea: controlador de tareas.

· Un manejador artificial de todos los Eventos del sistema de un caso de uso: controlador de casos de uso.

Cons

Potencial para reutilizar interfaces Conectables.

Razonamiento sobre el funcionamiento de Los casos de uso, es decir, valida la secuencia de operaciones, capturando Información de estado.

Ej-

¿Quién Debería ser el controlador de eventos sistémicos como introducirProducto y terminarVenta?

De acuerdo con el patrón Controlador, Disponemos de las siguientes opciones:

TPDV

Representa el “sistema” Global.

Tienda

Representa la empresa u Organización global.

Cajero

Representa algo en el mundo Real que está activo (por ejemplo, el papel de una persona) y que puede Intervenir en la tarea.

ManejadordeComprarProductos

Representa un manejador artificial de todas las operaciones del sistema de un Caso de uso.

Patr-
Command, Fachada, Capas, Fabricación Pura.

GRASP-
6 - Polimorfismo

P- ¿Cómo manejar las alternativas basadas en El tipo? ¿De qué manera crear componentes software conectables?

R-
Cuando el comportamiento relacionado Varía según el tipo (clase) asigne la responsabilidad para el comportamiento [utilizando operaciones polimórficas] a los tipos para los que varía el Comportamiento.

Evítense las comprobaciones acerca del Tipo de un objeto y procure no utilizar la lógica condicional.

Cons

Se añaden fácilmente extensiones Necesarias para nuevas variaciones.

Las nuevas Implementaciones se introducen sin afectar a los clientes.

Ej

Patr-
Variaciones Protegidas, Varios de los patrones de diseño GoF como Adaptador, Command, Composite, Proxy, Estado y Estrategia.

GRASP-
7 – Fabricación Pura

P-¿Qué objetos deberían tener la Responsabilidad cuando no se quiere violar los objetivos de alta cohesión y Bajo acoplamiento?

R-
Asigne un conjunto de responsabilidades Altamente cohesivas a una clase artificial que no representa un concepto del Dominio.

Cons

Se soporta alta cohesión puesto que las Responsabilidades se factorizan en una clase de grano fino.

El potencial para reutilizar aumenta.

Ej-
Se necesita soporte para almacenar la Venta en una base de datos se podría suponer según el Experto que la Propia clase debería tener la responsabilidad.

La Tarea implica un número amplio de operaciones de bases de datos no relacionadas Con las ventas (Baja cohesión)
.

Además tiene que acoplarse con el Interfaz de la base de datos.

Y por último la tarea de almacenar objetos puede ser Necesaria para más objetos.

Podríamos crear una clase AlmacenamientoPersistente.

Cont-
Llevar el principio al extremo.

Patr-
Bajo Acoplamiento, Alta Cohesión, los GoF (Adaptador, Command, Estrategia, etc) Y prácticamente el resto de patrones de diseño.

GRASP-
8 - Indirección

P- ¿Dónde asignar una responsabilidad para Evitar el acoplamiento directo entre dos objetos?

R-
Asigne la responsabilidad a un objeto Intermedio que medie entre otros componentes para que no estén acoplados Directamente, el intermediario crea un indirección.

Cons-
Disminuye el acoplamiento entre Componentes.

Ej-
Muchos de los patrones existentes son Especializaciones de Indirección.

Patr-
Está relacionado con Variaciones Protegidas, Bajo Acoplamiento, muchos GoF como Adaptador, Puente, Fachada, Observador y Mediador.

GRASP-
9 – Variaciones Protegidas

P- ¿Cómo diseñar componentes de manera que Las variaciones en ellos no tengan repercusión en otros elementos?

R-
Asigne responsabilidades para crear una Interfaz estable alrededor de los puntos de variaciones previstas o Inestabilidad.

Cons

Se añaden fácilmente las extensiones para Nuevas variaciones.

Se pueden introducir nuevas Implementaciones sin afectar a los clientes.

Se reduce el Acoplamiento.

Ej-
Mediante la Indirección de la interfaz y El polimorfismo se consigue una protección frente a las variaciones en las Interfaces externas, integrando el sistema con otros sistemas externos.

Patr-
La mayoría de los patrones son mecanismos De Variaciones Protegidas.
Se Relaciona con Polimorfismo, Indirección y la mayor parte de los GoF.

GoF - 1 - Singleton (creación)

P-¿Cómo Podemos asegurar que una clase tiene exactamente una única instancia y que ésta sea fácilmente accesible?

R-Defina un método estático de la clase que devuelva el Singleton

Cons

Permite El manejo de objetos únicos y que sean accesibles a otros objetos.

Acceso Controlado a la única instancia.

Ej

Patr-

Se utiliza a menudo Para Factoría y Fachada.

GoF-
2 - Factoría (creación)

P-¿Quién es el responsable de la creación de objetos Cuando existen consideraciones especiales, como una lógica de creación compleja O el deseo de separar las responsabilidades de la creación para mejorar la Cohesión?

R-Cree un objeto Fabricación Pura denominado Factoría (Factoría Concreta) que resuelva la creación Cuando existan consideraciones especiales.

Cons

Separar La responsabilidad de la creación compleja en objetos de apoyo.

Ocultar La lógica de creación potencialmente compleja.

Permitir Introducir estrategias para mejorar el rendimiento de la gestión de memoria.

Ej-

¿Quién crea Adaptador y cuál debería crearse?

Si Se encarga a algún objeto de dominio excedería la lógica de la aplicación o Disminuiría su cohesión. Resulta mejor asignar a una FactoriaDeServicios dicha responsabilidad, así se crea el Adaptador Dinámicamente. De esta manera se podría cambiar de Adaptador sin cambiar Código.

Patr-
A menudo se accede a las factorías con el Patrón Singleton

GoF-
4 -Adaptador-Wrapper (estructural)

P-¿Cómo resolver interfaces incompatibles, o Proporcionar una interfaz estable para componentes parecidos con diferentes Interfaces?

R-Convierta la interfaz de una clase en otra interfaz Que es la que esperan los clientes, permite que cooperen clases que de otra Forma no podrían cooperar por tener interfaces incompatibles.

Cons

·Posibilidad De reutilizar las clases que han sido pensadas para este Objetivo pero que Tenían interfaces no compatibles con el sistema en desarrollo.

·Un adaptador de objetos permite adaptar una clase y sus subclases, puede funcionar Para varios adaptables.

Ej-

El Adaptador Ofrece Variaciones Protegidas en Paquetes de terceras partes mediante un objeto Indirección que aplica Interfaces Y Polimorfismo.

Participantes

Objetivo-
Define la interfaz que utiliza el Cliente.

   Cliente-Colabora con objetos que se ajustan a la interfaz Objetivo.

   Adaptable-
Define una interfaz existente que necesita ser adaptada.

   Adaptador-
Adapta la interfaz de Adaptable a la interfaz Objetivo.

Patr-
Un adaptador de recursos oculta que un Sistema externo podría también ser considerado un objeto Fachada puesto que envuelve el acceso al subsistema o sistema con Un único objeto (Que es la esencia de la Fachada)
. Sin embargo, el nombre de Adaptador está Motivado especialmente cuando el objeto que envuelve facilita la adaptación a Diversas interfaces externas.

GoF-
5 -Composite (estructural)

P-¿Cómo Tratar un Grupo o una estructura compuesta del mismo modo que un objeto atómico?

R- Defina Las clases para los objetos compuestos y atómicos de manera que implementen el Mismo interfaz

Cons

Define Jerarquías parte/todo.

Los Clientes ignoran la diferencia entre objetos compuestos y objetos individuales Que los forman, pueden tratar objetos primitivos y compuestos de modo uniforme.

Jerarquía Con clases que modelan objetos primitivos y objetos compuestos, se permite Composición recursiva.

Es Fácil añadir nuevos tipos de componentes.

Ej-

Se puede crear una estrategia que implemente la misma Interfaz y que al mismo tiempo englobe varias estrategias, se van añadiendo en Distintos puntos.

Participantes

Componente-
Declara La interfaz para los objetos de la composición e implementatambién los métodos que determinan el comportamiento de las Diferentes clases tanto compuestas como hijas y permite tener acceso a Componentes en la estructura recursiva.

Hoja-
Define el comportamiento de los Objetos que no tienen hijos en la composición.

Compuesto-
Maneja Los hijos de los diferentes componentes compuestos y determinael comportamiento de aquellos Componentes capaces de tener hijos.

Cliente-
Manipula Los objetos de la composición a través del componente.

Patr-
El Patrón Composite se utiliza Normalmente junto con los patrones Estrategia Y Command.
El Composite se basa en Poliformismo Y proporciona Variacios Protegidas a Los clientes de manera que no les afecta si el objeto con el que se relacionan Es atómico o compuesto.

GoF-
8 -Estrategia (comportamiento)

P-¿Cómo Diseñar Diversos algoritmos o políticas que estén relacionadas? ¿Cómo diseñar que éstos Puedan cambiar?

R-Defina cada algoritmo, política o estrategia en una Clase independiente con una interfaz común

Cons

Configurar Una clase con uno de varios comportamientos posibles.

Se Necesitan diferentes variantes de un algoritmo para un mismo comportamiento.

Una Clase define muchos comportamientos que aparecen como sentencias CASE en sus Métodos, elimina sentencias CASE.

El Cliente puede elegir entre diferentes estrategias o implementaciones pero debe conocer Los detalles que las diferencian.

Participantes

Estrategia-
Interfaz común a Todos los algoritmos permitidos.

Estrategia concreta-
Implementa Los algoritmos correspondientes, usando la interfazEstrategia.

Contexto-
Mantiene Una referencia al objeto Estrategia, se configura con un objetoEstrategia Concreta.

Ej

Patr-

Se crea mediante una Factoría que se accede como Singleton.