Ingeniería del SoftwareAntonio Navarro
1
14. Patrones de diseño orientado a objetos
Ingeniería del SoftwareAntonio Navarro
2
Índice
• Introducción• Ejemplos
– MVC: Modelo Vista Controlador.– Fachada.– Factoría abstracta
Patrones GRASP– Introducción– Experto.
Ingeniería del SoftwareAntonio Navarro
3
Índice
– Creador.– Alta cohesión.– Bajo acoplamiento. – Controlador.– Polimorfismo.– Fabricación pura.– Indirección.– No hables con extraños
Ingeniería del SoftwareAntonio Navarro
4
Índice
– Nota.• Patrones Gamma
– Clasificación• Patrones de creación
– Abstract factory.– Builder.– Factory method.
Ingeniería del SoftwareAntonio Navarro
5
Índice
– Prototype.– Singleton.
• Patrones estructurales– Adapter.– Bridge.– Composite.– Decorator.– Facade.
Ingeniería del SoftwareAntonio Navarro
6
Índice
– Flyweight.– Proxy.
• De comportamiento– Chain of responsability.– Command.– Interpreter.– Iterator.– Mediator.
Ingeniería del SoftwareAntonio Navarro
7
Índice
– Memento.– Observer.– State.– Strategy.– Template method.– Visitor.
• Relaciones entre patrones Gamma• Conclusiones
Ingeniería del SoftwareAntonio Navarro
8
Introducción
• Según Christopher Alexander, “un patróndescribe un problema que ocurre una y otra vez en nuestro entorno, así como la solución a ese problema de tal modo que se puede aplicar esta solución un millón de veces, sin hacer lo mismo dos veces”
Ingeniería del SoftwareAntonio Navarro
9
Introducción
• Aunque Alexander se refería a patrones en ciudades y edificios, lo que dice también es válido para patrones de diseño OO
• Podemos decir que los patrones de diseño:- Son soluciones simples y elegantes a problemas específicos del diseño de software OO.- Representan soluciones que han sido desarrolladas y han ido evolucionando a través del tiempo.
Ingeniería del SoftwareAntonio Navarro
10
Introducción
• Los patrones de diseño no tienen en cuenta cuestiones tales como:- Estructuras de datos.- Diseños específicos de un dominio.
• Son descripciones de clases y objetos relacionados que están particularizados para resolver un problema de diseño general en un determinado contexto
Ingeniería del SoftwareAntonio Navarro
11
Introducción
• Cada patrón de diseño identifica:- Las clases e instancias participantes.- Los roles y colaboraciones de dichas clases e instancias.- La distribución de responsabilidades
• Veremos dos familias de patrones:- GRASP*, de Craig Larman.- Los patrones Gamma, de Eric Gamma et al.
*General Responsability Asignment Software PatternsIngeniería del SoftwareAntonio Navarro
12
EjemplosMVC
• El patrón/arquitectura Modelo Vista Controlador MVC divide una aplicación interactiva en tres componentes:- El modelo contiene la funcionalidad básica y los datos.- Las vistas muestran información al usuario.- Los controladores manejan las entradas del usuario.
Ingeniería del SoftwareAntonio Navarro
13
EjemplosMVC
Patrón MVCIngeniería del SoftwareAntonio Navarro
14
EjemplosMVC
• Participantes en MVC. Modelo activo:
Participantes en MVC. Modelo activo
+maneja eventos
Controlador
Vista Modelo+actualiza+accede
+actúa
+genera eventos
Ingeniería del SoftwareAntonio Navarro
15
EjemplosMVC
• Interacción en MVC. Modelo activo:
: : usuario
: Vista : Controlador : Modelo
interac túaevento
actúa
actualiza
accede
Interacción en MVC. Modelo activoIngeniería del SoftwareAntonio Navarro
16
EjemplosMVC
Controlador
ModeloVista
+maneja eventos +actúa+actual iza
+genera eventos
+accede
• Participantes en MVC. Modelo pasivo:
Participantes en MVC. Modelo pasivo
Ingeniería del SoftwareAntonio Navarro
17
EjemplosMVC
• Interacción en MVC. Modelo pasivo:
: : usuario : Vista : Controlador : Modelo
interactúaevento
actúa
accede
actualiza
Interacción en MVC. Modelo pasivoIngeniería del SoftwareAntonio Navarro
18
EjemplosMVC
• Ejemplo*:class Controlador implements ActionListener{
............................public void actionPerformed (ActionEvent e){
modelo.sumar();}
}
*Modelo activo sin utilizar java.util.Observer
Ingeniería del SoftwareAntonio Navarro
19
EjemplosMVC
class Modelo {int valor;IVista vista;.................void sumar(){ valor++;
vista.actualizar(this); }int obtenerValor(){ return valor; }
}Ingeniería del SoftwareAntonio Navarro
20
EjemplosMVC
public interface IVista {void actualizar(Object actualizado);
}
Ingeniería del SoftwareAntonio Navarro
21
EjemplosMVC
class Vista extends JFrame implements IVista {..........................public void actualizar (Object o){Modelo modelo= (Modelo) o;Integer i= new Integer(modelo.obtenerValor());valor.setText(i.toString());}
..........................}
Ingeniería del SoftwareAntonio Navarro
22
EjemplosMVC
• En los ejemplos anteriores la vista que envía los eventos al controlador, es la misma que recibe las actualizaciones del modelo/controlador
• En general, esto no tiene porque ser así (e.g. aplicaciones Web)
Ingeniería del SoftwareAntonio Navarro
23
EjemplosMVC
• Respecto al número de controladores, puede haber:- Uno por evento.- Uno por conjuntos de funcionalidades/estímulos.- Uno por aplicación.
Ingeniería del SoftwareAntonio Navarro
24
EjemplosMVC
• Además, podemos ver al controlador como un componente que traduce la interacción con el usuario en eventos del negocio
• La interacción del controlador con el modelo, puede hacerse de dos formas:
Ingeniería del SoftwareAntonio Navarro
25
EjemplosMVC
eventoi controlador
modelo.funcioni(datosi)
modelo.procesa(codigo_eventoi, objeto_datosi)
(a)
(b)
Interacción del controlador con el modelo
Ingeniería del SoftwareAntonio Navarro
26
EjemplosMVC
• La opción (a) conlleva:- La presencia de una clase que actúa como fachada centralizando el acceso a través de ella y seleccionando el módulo responsable del procesamiento (i.e. modelo ~ fachada).- Menor mantenibilidad.- Mayor sencillez.
Ingeniería del SoftwareAntonio Navarro
27
EjemplosMVC
• La opción (b) conlleva:- La presencia de una clase que procesa los eventos del negocio seleccionando el componente responsable del procesamiento (i.e. modelo ~ controlador eventos negocio).- Mayor mantenibilidad.- Mayor complejidad.
Ingeniería del SoftwareAntonio Navarro
28
EjemplosMVC
• Por ejemplo, el controlador de JakartaStruts*, sigue la filosofía (b), aunque también se encarga de capturar los datos de la interfaz asociados al evento y de encapsularlos en un objeto adecuado
*http://struts.apache.org/
Ingeniería del SoftwareAntonio Navarro
29
EjemplosMVC
• No se contempla la posibilidad de invocar directamente a módulos por:- Obligaría a conocer el número de subsistemas y las funciones de estos.- En arquitecturas simples, la fachada puede ser un mediador entre subsistemas.
Ingeniería del SoftwareAntonio Navarro
30
EjemplosMVC
• Ventajas:- Modelo independiente de la representación de la salida y del comportamiento de la entrada.- Puede haber múltiples vistas para un mismo modelo.- Cambios independientes en interfaz/lógica.
• Inconvenientes- Complejidad
Ingeniería del SoftwareAntonio Navarro
31
EjemplosMVC
• Comentarios:- El patrón MVC es un caso particular del patrón observador.- Las vistas en MVC se pueden anidar. De esta forma una vista sería un caso particular del patrón compuesto.
Ingeniería del SoftwareAntonio Navarro
32
EjemplosMVC
• Enlaces recomendados sobre MVC:http://www.enode.com/x/markup/tutorial/mvc.htmlhttp://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpatterns/html/DesMVC.asp
• Enlaces no* recomendados sobre MVC:http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/
*Por estar fuera de los objetivos de esta asignatura
Ingeniería del SoftwareAntonio Navarro
33
EjemplosFachada
• El patrón fachada proporciona una interfaz unificada para un conjunto de interfaces de un subsistema
• Define una interfaz de alto nivel para que el subsistema sea más fácil de utilizar
• Cuando hablamos de subsistemas, nos referimos a los subsistemas de diseño
Ingeniería del SoftwareAntonio Navarro
34
EjemplosFachada
• Decíamos que tenían que estar formados por subsistemas cohesivos con bajo acoplamiento
• Los interfaces evitan el acoplamiento entre subsistemas de diseño
• Los subsistemas de diseño se plasman como paquetes
Ingeniería del SoftwareAntonio Navarro
35
EjemplosFachada
• Subsistemas de diseño, ejemplo:P1 P2
A B
P1 P2
AIB
<<Interface>> B
Dependencias entre paquetesIngeniería del SoftwareAntonio Navarro
36
EjemplosFachada
• Si la dependencia fuera asociación navegada, la responsabilidad de crear los elementos accedidos, no debería recaer sobre el objeto que los accede
• Solución:- Ya está creado y se pasa al que lo accede.- Se delega en otro objeto para crearlo: patrón factoría abstracta
Ingeniería del SoftwareAntonio Navarro
37
EjemplosFachada
• Ahora, no solamente utilizamos interfaces, sino además un interfaz de acceso a los interfaces: la fachada
• El patrón fachada permite estructurar un sistema en subsistemas
• Cada subsistema debe implementar sus responsibilidades
• De esta forma evitamos sistemas monolíticos
Ingeniería del SoftwareAntonio Navarro
38
EjemplosFachada
Patrón fachada
Ingeniería del SoftwareAntonio Navarro
39
EjemplosFachada
• Ventajas:- Oculta a los clientes los componentes del subsistema, reduciendo así el número de objetos con los que tratan los clientes. De esta forma el subsistema es más fácil de utilizar.- Promueve un débil acoplamiento entre el subsistema y los clientes.
- Muchas veces, dentro de un subsistema sus componentes están fuertemente acoplados.
Ingeniería del SoftwareAntonio Navarro
40
EjemplosFachada
- Al introducir la fachada podemos modificar los componentes del subsistema sin afectar a los clientes.- Además esto permite implementaciones independientes de subsistemas.- Esto último también se logra con simples interfaces.
- No impide que las aplicaciones utilicen las clases del subsistema en caso necesario.
• Inconvenientes:- Ninguno de peso.
Ingeniería del SoftwareAntonio Navarro
41
EjemplosFachada
• Ejemplo:public interface IBiblioteca {public void insertarLibro(String nombre, String autor);
public void insertarRevista(String nombre, intvolumen, int numero);
public void eliminarEjemplar(int id);public void insertarUsuario(String nombre);public void eliminarUsuario(int id);public void validarUsuario(int id);........... };
Ingeniería del SoftwareAntonio Navarro
42
EjemplosFachada
public class Biblioteca implements IBiblioteca {IEjemplares ejemplares;IUsuarios usuarios;IInterfazBiblioteca interfazBiblioteca;...........................public void insertarLibro(String nombre, String autor){ ejemplares.insertarLibro(nombre, autor);}
........... };
Ingeniería del SoftwareAntonio Navarro
43
EjemplosFactoría abstracta
• El patrón factoría abstracta proporciona una interfaz para crear familias de objetos relacionados o que dependen entre sí, sin especificar sus clases concretas
• Desliga la creación de nuevos objetos de la clase que se refiere a dichos objetos a través de la interfaz que implementan
Ingeniería del SoftwareAntonio Navarro
44
EjemplosFactoría abstracta
Patrón factoría abstracta
Ingeniería del SoftwareAntonio Navarro
45
EjemplosFactoría abstracta
Factoria abstracta para un conjunto de elementos de IGUIngeniería del SoftwareAntonio Navarro
46
EjemplosFactoría abstracta
• Ventajas:- Aísla las clases concretas que se crean en una aplicación y se manejan a través de los interfaces que implementan.- Facilita el intercambio de familias de productos.- Promueve la consistencia entre productos.
• Inconvenientes:- Nuevos tipos de productos provocan la redefinición de la factoría.
Ingeniería del SoftwareAntonio Navarro
47
EjemplosFactoría abstracta
• Ejemplo:public interface IEjemplares {
public void insertarLibro(String nombre, String autor);public void insertarRevista(Stringnombre, int volumen, int numero);public void eliminar(int id);
..................};
Ingeniería del SoftwareAntonio Navarro
48
EjemplosFactoría abstracta
public interface IUsuarios {
public void insertarUsuario(String nombre);public void eliminarUsuario(int id);public void validarUsuario(int id);
............};
Ingeniería del SoftwareAntonio Navarro
49
EjemplosFactoría abstracta
public class Ejemplares implementsIEjemplares {.......};
public class Usuarios implementsIUsuarios {.......};
Ingeniería del SoftwareAntonio Navarro
50
EjemplosFactoría abstracta
public interface IFactoriaBiblioteca {
public IEjemplares generarEjemplares();public IUsuarios generarUsuarios();
};
Ingeniería del SoftwareAntonio Navarro
51
EjemplosFactoría abstracta
public class FactoriaBiblioteca implements IFactoriaBiblioteca{
public IEjemplares generarEjemplares(){ return new Ejemplares(); }
public IUsuarios generarUsuarios(){ return new Usuarios(); }
};
Ingeniería del SoftwareAntonio Navarro
52
EjemplosFactoría abstracta
public class Biblioteca implements IBiblioteca{IEjemplares ejemplares;IUsuarios usuarios;
............public Biblioteca(IFactoriaBiblioteca factoriaBiblioteca) {ejemplares= factoriaBiblioteca.generarEjemplares();usuarios= factoriaBiblioteca.generarUsuarios();}
............ };
Ingeniería del SoftwareAntonio Navarro
53
Patrones GRASPIntroducción
• Un sistema orientado a objetos se compone de objetos que envían mensajes a otros objetos para que lleven a cabo operaciones
• La calidad de diseño de la interacción de los objetos y la asignación de responsabilidades presentan gran variación
Ingeniería del SoftwareAntonio Navarro
54
Patrones GRASPIntroducción
• Las decisiones poco acertadas dan origen a sistemas y componentes frágiles y difíciles de mantener, entender, reutilizar o extender
• Los patrones GRASP recogen principios/directrices para obtener buenos diseños OO que se aplican al preparar los diagramas de interacción y/o asignar responsabilidades
• Son menos concretos que los patrones Gamma
Ingeniería del SoftwareAntonio Navarro
55
Patrones GRASPIntroducción
• Los patrones GRASP son:- Experto.- Creador.- Alta cohesión.- Bajo acoplamiento.- Controlador.- Polimorfismo.- Fabricación pura.- Indirección.- No hables con extraños.
Ingeniería del SoftwareAntonio Navarro
56
Patrones GRASPExperto
• Problema: ¿cuál es el principio fundamental en virtud del cual se asignan las responsabilidades en el diseño OO?
• Solución: asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad
Ingeniería del SoftwareAntonio Navarro
57
Patrones GRASPExperto
• Ejemplo- Supongamos que tenemos una aplicación que gestiona ventas.- Queremos calcular el total de una venta sobre las siguientes clases:
Asociaciones de Venta
Ingeniería del SoftwareAntonio Navarro
58
Patrones GRASPExperto
Cálculo del total de la venta
Ingeniería del SoftwareAntonio Navarro
59
Patrones GRASPExperto
- Es decir, se ha decidido el siguiente reparto de responsabilidades:
- Venta: conoce el total de la venta.- VentasLineadeProducto: conoce el subtotal de la línea de producto.- EspecificacióndeProducto: conoce el precio del producto.
Ingeniería del SoftwareAntonio Navarro
60
Patrones GRASPExperto
• Comentarios- Experto es el patrón GRASP más usado.- Expresa la idea de que los objetos hacen cosas relacionadas con la información que poseen.- El cumplimiento de una responsabilidad frecuentemente requiere información distribuida en varias clases puede haber expertos parciales.
Ingeniería del SoftwareAntonio Navarro
61
Patrones GRASPExperto
• Beneficios- Se conserva el encapsulamiento bajo acoplamiento.- Promueve clases sencillas y cohesivas que son más fáciles de mantener y comprender
Ingeniería del SoftwareAntonio Navarro
62
Patrones GRASPCreador
• Problema: ¿Quién debería ser responsable de crear una nueva instancia de alguna clase?
• Solución: La clase B es responsable de crear una instancia de la clase A en uno de los siguientes casos:- B agrega los objetos A.- B contiene los objetos A.
Ingeniería del SoftwareAntonio Navarro
63
Patrones GRASPCreador
- B registra a las instancias de los objetos A.- B utiliza específicamente los objetos A.- B tiene los datos de inicialización que serán transmitidos a A cuando este objeto sea creado (Bes un experto respecto a la creación de A).
Ingeniería del SoftwareAntonio Navarro
64
Patrones GRASPCreador
• Ejemplo- En la aplicación de punto de venta, ¿quién debería encargarse de crear una instancia de VentasLineadeProducto?
Asociacionesde Venta
Ingeniería del SoftwareAntonio Navarro
65
Patrones GRASPCreador
- Una Venta contiene muchos objetos VentasLineadeProducto, por lo que es idónea para asumir la responsabilidad de la creación.
Creación de un objeto VentasLineadeProductoIngeniería del SoftwareAntonio Navarro
66
Patrones GRASPCreador
• Comentarios- El patrón creador guía la asignación de responsabilidades relacionadas con la creación de objetos.- El propósito fundamental es encontrar un creador que debemos conectar con el objeto producido, dando soporte a un bajo acoplamiento.- Nótese que el creador es un experto en creación.
Ingeniería del SoftwareAntonio Navarro
67
Patrones GRASPCreador
• Beneficios- Proporciona un bajo acoplamiento, pues la clase creada tiende a ser visible a la clase creador.
Ingeniería del SoftwareAntonio Navarro
68
Patrones GRASPBajo acoplamiento
• Problema: ¿Cómo dar soporte a una dependencia escasa y a un aumento de la reutilización?
• Solución: asignar una responsabilidad para mantener bajo acoplamiento
Ingeniería del SoftwareAntonio Navarro
69
Patrones GRASPBajo acoplamiento
• Ejemplo- En el ejemplo del terminal del punto de venta, ¿quién debe crear un Pago?
Clases involucradas
Ingeniería del SoftwareAntonio Navarro
70
Patrones GRASPBajo acoplamiento
Diseño 1
Diseño 2
Ingeniería del SoftwareAntonio Navarro
71
Patrones GRASPBajo acoplamiento
- El patrón experto podría recomendar el diseño 1.- El patrón bajo acoplamiento podría recomendar el diseño 2.
• Comentarios - En los lenguajes orientados a objetos, las formas más comunes de acoplamiento de TipoA y TipoBson las siguientes:
- TipoA tiene un atributo de TipoB.
Ingeniería del SoftwareAntonio Navarro
72
Patrones GRASPBajo acoplamiento
- TipoA tiene un método que involucra a una instancia de TipoB (entrada, salida, cuerpo).- TipoA es subclase de TipoB.- TipoB es una interfaz y TipoA la implementa.
- El bajo acoplamiento estimula asignar una responsabilidad de modo que su colocación no incremente el acoplamiento tanto que produzca los resultados negativos propios de un alto acoplamiento.
Ingeniería del SoftwareAntonio Navarro
73
Patrones GRASPBajo acoplamiento
- Bajo acoplamiento soporta el diseño de clases más independientes, que reducen el impacto de los cambios, y también más reutilizables, que acrecientan la oportunidad de una mayor productividad.- El acoplamiento no es tan importante si no se busca la reutilización (análisis coste-beneficio).- Una subclase está acoplada con su superclase, luego la derivación será estudiada con cuidado.
Ingeniería del SoftwareAntonio Navarro
74
Patrones GRASPBajo acoplamiento
• Beneficios- Los cambios en otros componentes no afectan.- Clases fáciles de entender por separado.- Clases fáciles de reutilizar.
Ingeniería del SoftwareAntonio Navarro
75
Patrones GRASPAlta cohesión
• Problema: ¿cómo mantener la complejidad dentro de límites manejables?
• Solución: asignar una responsabilidad a una clase de modo que la cohesión siga siendo alta
• Ejemplo:- Consideremos los diseños anteriores:
Ingeniería del SoftwareAntonio Navarro
76
Patrones GRASPAlta cohesión
Diseño 1
Diseño 2
Ingeniería del SoftwareAntonio Navarro
77
Patrones GRASPAlta cohesión
- El diseño 1 puede llevar a una clase TPDVsaturado y sin cohesión- El diseño 2 proporciona una mayor cohesión de las clases involucradas.
• Comentarios- Una clase de alta cohesión posee un número relativamente pequeño de responsabilidades, con una importante funcionalidad relacionada y poco trabajo por hacer. Colabora con otros objetos para compartir el esfuerzo si la tarea es grande.
Ingeniería del SoftwareAntonio Navarro
78
Patrones GRASPAlta cohesión
- Una clase con mucha cohesión es útil porque es bastante fácil darle mantenimiento, entenderla y reutilizarla.- No tiene nada que ver una clase cohesiva con una fachada, ya que la fachada delega en las clases a las que oculta.
• Beneficios- Mejoran la claridad y facilidad con que se entiende el diseño.
Ingeniería del SoftwareAntonio Navarro
79
Patrones GRASPAlta cohesión
- Se simplifica el mantenimiento y las mejoras en la funcionalidad.- A menudo se genera un bajo acoplamiento.
Ingeniería del SoftwareAntonio Navarro
80
Patrones GRASPControlador
• Problema: ¿quién debería encargarse de atender un evento del sistema?
• Un evento del sistema es un evento de alto nivel generado por una actor externo, es un evento de entrada externa
• Se asocia a operaciones del sistema, las que emite en respuesta a los eventos del sistema.
Ingeniería del SoftwareAntonio Navarro
81
Patrones GRASPControlador
• Solución: 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).
Ingeniería del SoftwareAntonio Navarro
82
Patrones GRASPControlador
- 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, generalmente denominados “Manejador<NombreCasodeUso>”(controlador de casos de uso).
Ingeniería del SoftwareAntonio Navarro
83
Patrones GRASPControlador
• Ejemplo- En el caso del terminal del punto de venta, ¿quién debería encargarse de introducir un producto?:
- El representante del sistema: TPDV.- El representante de la empresa: Tienda.- Algo activo del mundo real: Cajero.- Manejador caso de uso: ManejadordeComprarProductos.
Ingeniería del SoftwareAntonio Navarro
84
Patrones GRASPControlador
Distintas opciones para el controlador
Ingeniería del SoftwareAntonio Navarro
85
Patrones GRASPControlador
• Comentarios- El patrón ofrece una guía para tomar decisiones sobre los eventos de entrada.- Sea como fuere, los elementos de interfaz, y sus controladores de eventos de interfaz, no deben ser responsables de controlar los eventos del sistema
Ingeniería del SoftwareAntonio Navarro
86
Patrones GRASPControlador
• Beneficios- Mayor potencial de los componentes reutilizables.- Reflexionar sobre el estado del caso de uso.
Ingeniería del SoftwareAntonio Navarro
87
Patrones GRASPPolimorfismo
• Problema: ¿cómo manejar las alternativas basadas en el tipo?
• Solución: cuando por el tipo varían las alternativas o los comportamientos afines, las responsabilidades del comportamiento se asignarán mediante operaciones polimórficas a los tipos en el que el comportamiento presenta variantes
Ingeniería del SoftwareAntonio Navarro
88
Patrones GRASPPolimorfismo
• Por lo tanto no se deben realizar pruebas con el tipo de un objeto ni utilizar lógica condicional para plantear diversas alternativas basadas en el tipo
• Ejemplo- En el caso del terminal del punto de venta, ¿quién debería encargarse de autorizar las diversas clases de pagos?
Ingeniería del SoftwareAntonio Navarro
89
Patrones GRASPPolimorfismo
Polimorfismo en la autorización de pagosIngeniería del SoftwareAntonio Navarro
90
Patrones GRASPPolimorfismo
• Comentarios- Experto es un patrón táctico, mientras que polimorfismo es estratégico.- Representa un principio fundamental del modelo de objetos.
• Beneficios- Es fácil incluir futuras extensiones.- Permite tratar de manera uniforme objetos distintos.
Ingeniería del SoftwareAntonio Navarro
91
Patrones GRASPFabricación pura
• Problema: ¿a quién asignar la responsabilidad cuando uno estádesesperado y no quiere violar los patrones alta cohesión y bajo acoplamiento?
• Solución: asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial que no representa nada en el dominio del problema
Ingeniería del SoftwareAntonio Navarro
92
Patrones GRASPFabricación pura
• Ejemplo- Supongamos que queremos dar persistencia a las ventas.- Si la clase Venta es responsable de su persistencia:
- La clase Venta reduce su cohesión.- La clase Venta aumenta su acoplamiento.
Ingeniería del SoftwareAntonio Navarro
93
Patrones GRASPFabricación pura
- Es decir, aunque venta parece el experto para su persistencia, en base a la cohesión y el acoplamiento decidimos crear una clase artificial cuya finalidad única es guardar al objeto.
PersistenciaVenta
guardar()leer()
Fabricación pura
Ingeniería del SoftwareAntonio Navarro
94
Patrones GRASPFabricación pura
- Nótese que en un entorno polimórfico, esta solución obliga a vincular a cada objeto con su clase de persistencia correspondiente. De otra forma habría que razonar directamente sobre el tipo.
• Comentarios- Clases con responsabilidades de granularidadfina.
Ingeniería del SoftwareAntonio Navarro
95
Patrones GRASPFabricación pura
- Patrones como el adaptador, observador, visitante son ejemplos de fabricaciones puras.
• Beneficios- Alta cohesión.- Aumenta el potencial de reutilización
Ingeniería del SoftwareAntonio Navarro
96
Patrones GRASPIndirección
• Problema: ¿a quién se asignarán las responsabilidades con el fin de evitar el acoplamiento directo?
• Solución: se asigna la responsabilidad a un objeto intermedio para que medie entre otros componentes o servicios, y éstos no terminen directamente acoplados
Ingeniería del SoftwareAntonio Navarro
97
Patrones GRASPIndirección
• Ejemplo- La clase PersistenciaVenta es también un ejemplo de indirección.- Venta delega en otra clase una funcionalidad con el fin de disminuir el acoplamiento.
• Beneficios- Bajo acoplamiento.
Ingeniería del SoftwareAntonio Navarro
98
Patrones GRASPNo hables con extraños
• Problema: ¿a quién asignar las responsabilidades para evitar conocer la estructura de los objetos indirectos?
• Solución: se asigna la responsabilidad a un objeto directo del cliente para que colabore con un objeto indirecto, de modo que el cliente no necesite saber nada del objeto indirecto
Ingeniería del SoftwareAntonio Navarro
99
Patrones GRASPNo hables con extraños
• El patrón, también conocido con el nombre de ley de Demeter, impone restricciones a los objetos a los cuales deberíamos enviar mensajes dentro de un método
• El patrón establece que en un método, los mensajes sólo deberían ser enviados a los siguientes objetos:- El objeto this.
Ingeniería del SoftwareAntonio Navarro
100
Patrones GRASPNo hables con extraños
- Un parámetro del método.- Un atributo de this.- Un elemento de una colección que sea atributo de this.- Un objeto creado en el interior del método.
• Ejemplo- Supongamos que queremos conocer el total (monto) de un pago en una venta.
Ingeniería del SoftwareAntonio Navarro
101
Patrones GRASPNo hables con extraños
Asociaciones entre clases
Ingeniería del SoftwareAntonio Navarro
102
Patrones GRASPNo hables con extraños
Violación del patrón
Ingeniería del SoftwareAntonio Navarro
103
Patrones GRASPNo hables con extraños
Implementación del patrón
Ingeniería del SoftwareAntonio Navarro
104
Patrones GRASPNo hables con extraños
- Venta agrega la responsabilidad de obtener el total.- A esto se le conoce como promoción de la interfaz.
• Comentarios- El patrón evita una visibilidad temporal frente a objetos indirectos, que son de conocimiento de otros objetos, pero no del cliente.
Ingeniería del SoftwareAntonio Navarro
105
Patrones GRASPNo hables con extraños
- De esta forma se evitan acoplamientos innecesarios.- El patrón puede violarse en el caso de que el objeto intermedio sea un agente encargado de extraer datos.
• Beneficios- Bajo acoplamiento.
Ingeniería del SoftwareAntonio Navarro
106
Patrones GRASPNota
• Los patrones GRASP podemos asimilarlos a directrices del modelo de objetos:- Las clases deben tener responsabilidades definidas, en base a los papeles que desempeñen.
- Patrón experto.- Patrón creador.- Patrón controlador.
Ingeniería del SoftwareAntonio Navarro
107
Patrones GRASPNota
- Las clases no deben ser monolíticas, deben delegar en otras clases para llevar a cabo su funcionalidad.
- Patrón indirección.
- Cuando objetos ligados por tramas de herencia usen lógicas case en base al tipo, debemos utilizar polimorfismo.
- Patrón polimorfismo.
Ingeniería del SoftwareAntonio Navarro
108
Patrones GRASPNota
- En el proceso de análisis y diseño pueden aparecer clases que no están relacionadas con el dominio del problema, pero sí con la solución.
- Fabricación pura.
- Las clases (y en general los módulos/subsistemas/paquetes), deben tener una alta cohesión.
- Alta cohesión.
Ingeniería del SoftwareAntonio Navarro
109
Patrones GRASPNota
- Las clases (y en general los módulos/subsistemas/paquetes), deben tener un bajo acoplamiento.
- Bajo acoplamiento.- No hables con extraños.
• En este sentido, son más normas que patrones
Ingeniería del SoftwareAntonio Navarro
110
Patrones GammaClasificación
• Podemos clasificar los patrones de diseño en base a su:- Propósito: lo que hace el patrón
- Creación: creación de objetos- Estructural: composición de clases u objetos.- Comportamiento: modo en que las clases y objetos interactúan y se reparten la responsabilidad
Ingeniería del SoftwareAntonio Navarro
111
Patrones GammaClasificación
- Ámbito: especifica si el patrón se aplica principalmente a clases o a objetos
- Clases: centrados en relaciones entre clases y sus subclases, es decir, relaciones estáticas de compilación.- Objetos: relaciones entre objetos, que pueden cambiarse en tiempo de ejecución y son más dinámicas
Ingeniería del SoftwareAntonio Navarro
112
Patrones GammaClasificación
• De esta forma los patrones:- creación + clases: delegan alguna parte del proceso de creación de objetos en las subclases.- creación + objetos: delegan alguna parte del proceso de creación de objetos en otros objetos.- estructurales + clases: usan la herencia para componer clases.- estructurales + objetos: describen formas de ensamblar objetos.
Ingeniería del SoftwareAntonio Navarro
113
Patrones GammaClasificación
- comportamiento + clases: usan la herencia para describir algoritmos y flujos de control.- comportamiento + objetos: describen cómo cooperan un grupo de objetos para realizar una tarea que ningún objeto puede llevar a cabo por si solo.
Ingeniería del SoftwareAntonio Navarro
114
Patrones GammaClasificación
Patrones de diseño Gamma
Ingeniería del SoftwareAntonio Navarro
115
Patrones GammaClasificación
• En cualquier caso, la clasificación no es única
• Otra clasificación podría hacerse es atendiendo a las relaciones existentes entre los patrones de diseño
Ingeniería del SoftwareAntonio Navarro
116
Relaciones entre
patrones Gamma
Relaciones entre patrones Gamma
Ingeniería del SoftwareAntonio Navarro
117
Patrones GammaClasificación
• Para cada patrón veremos:– Propósito.– También conocido cómo.– Motivación.– Aplicabilidad.– Estructura.– Consecuencias– Código de ejemplo.
Ingeniería del SoftwareAntonio Navarro
118
Patrones de creaciónAbstract Factory
• Propósito – Proporciona una interfaz para crear familias de
objetos relacionados o que dependen entre sí, sin especificar sus clases concretas
• También conocido como– Fábrica Abstracta– Kit
Ingeniería del SoftwareAntonio Navarro
119
Patrones de creaciónAbstract Factory
• Motivación– Supongamos que deseamos tener una interfaz
de usuario independiente de los objetos concretos que la componen.
– Si la aplicación crea instancias de clases o útiles específicos de la interfaz de usuario será difícil cambiar ésta más tarde.
Ingeniería del SoftwareAntonio Navarro
120
Patrones de creaciónAbstract Factory
Patrón Abstract Factory
Ingeniería del SoftwareAntonio Navarro
121
Patrones de creaciónAbstract Factory
• Debemos aplicar el patrón cuando:- Un sistema debe ser independiente de cómo se crean, componen y representan sus productos.- Un sistema debe ser configurado con una familia de productos de entre varias.- Una familia de objetos producto relacionados está diseñada para ser usada conjuntamente, y es necesario hacer cumplir esta restricción.
Ingeniería del SoftwareAntonio Navarro
122
Patrones de creaciónAbstract Factory
- Quiere proporcionar una biblioteca de clases de productos, y sólo quiere revelar sus interfaces, no sus implementaciones.
• Estructura
Ingeniería del SoftwareAntonio Navarro
123
Patrones de creaciónAbstract Factory
Estructura del Abstract Factory
Ingeniería del SoftwareAntonio Navarro
124
Patrones de creaciónAbstract Factory
• Consecuencias de Abstract Factory:- Ventajas:
- Aísla las clases concretas de sus clientes.- Facilita el intercambio de familias de productos.- Promueve la consistencia entre productos.
- Inconvenientes:- Es difícil dar cabida a nuevos tipos de productos, ya que hay que modificar FabricaAbstracta.
Ingeniería del SoftwareAntonio Navarro
125
Patrones de creaciónAbstract Factory
• Cógido de ejemplo- Supongamos que deseamos construir un juego de laberintos.- Deseamos que los laberintos que construyamos no dependan de los objetos (e.g. pared) concretos que lo componen.- Así podemos tener distintos niveles, para los mismos escenarios.
Ingeniería del SoftwareAntonio Navarro
126
Patrones de creaciónAbstract Factory
public interface FabricaDeLaberintos {public Laberinto hacerLaberinto();public Pared hacerPared();public Habitacion hacerHabitacion();public Puerta hacerPuerta();
};
Ingeniería del SoftwareAntonio Navarro
127
Patrones de creaciónAbstract Factory
public class JuegoDelLaberinto {.........Laberinto crearLaberinto(FabricaDeLaberinto fabrica){
Laberinto l= fabrica.hacerLaberinto();Habitacion h1= fabrica.hacerHabitacion();Habitacion h2= fabrica.hacerHabitacion();Puerta p= fabrica.hacerPuerta(h1, h2);
l.anadirHabitacion(h1);l.anadirHabitacion(h2);
Ingeniería del SoftwareAntonio Navarro
128
Patrones de creaciónAbstract Factory
h1.establecerLado(Norte, fabrica.hacerPared());h1.establecerLado(Este, p);h1.establecerLado(Sur, fabrica.hacerPared());h1.establecerLado(Oeste, fabrica.hacerPared());
h2.establecerLado(Norte, fabrica.hacerPared());h2.establecerLado(Este, fabrica.hacerPared());h2.establecerLado(Sur, fabrica.hacerPared());h2.establecerLado(Oeste, p)
return l; }
Ingeniería del SoftwareAntonio Navarro
129
Patrones de creaciónAbstract Factory
class FabricaDeLaberintosEncantados implementsFabricaDeLaberintos {.......Habitacion hacerHabitacion(int n){ return new HabitacionEncantada(n); }
Puerta hacerPuerta(Habitacion h1, Habitacion h2){ return new PuertaEncantada(h1, h2); }........
};
Ingeniería del SoftwareAntonio Navarro
130
Patrones de creaciónAbstract Factory
class FabricaDeLaberintosExplosivos implementsFabricaDeLaberintos {.......Habitacion hacerHabitacion(int n){ return new HabitacionExplosiva(n); }
Puerta hacerPuerta(Habitacion h1, Habitacionh2){ return new PuertaExplosiva(h1, h2); }........
};
Ingeniería del SoftwareAntonio Navarro
131
Patrones de creaciónAbstract Factory
JuegoDelLaberinto juego= new JuegoDelLaberinto();FabricaDeLaberintosExplosivos fabrica = new
FabricaDeLaberintosExplosivos();
juego.crearLaberinto(fabrica);
Ingeniería del SoftwareAntonio Navarro
132
Patrones de creaciónBuilder
• Propósito– Separa la construcción de un objeto complejo
de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones del objeto.
• También conocido como– Constructor.
Ingeniería del SoftwareAntonio Navarro
133
Patrones de creaciónBuilder
• Motivación- Supongamos que deseamos construir un editor RTF que pueda convertir un texto a distintos formatos.- El número de formatos no debería estar determinado a priori.
Ingeniería del SoftwareAntonio Navarro
134
Patrones de creaciónBuilder
Patrón Builder
Ingeniería del SoftwareAntonio Navarro
135
Patrones de creaciónBuilder
• El patrón Builder se debe aplicar cuando:- El algoritmo para crear un objeto complejo debería ser independiente de las partes de que compone dicho objeto y de cómo se ensamblan.- El proceso de construcción debe permitir diferentes representaciones del objeto que estásiendo construido.
• Estructura
Ingeniería del SoftwareAntonio Navarro
136
Patrones de creaciónBuilder
Estructura del patrón Builder
Ingeniería del SoftwareAntonio Navarro
137
Patrones de creaciónBuilder
Colaboraciones en el patrón BuilderIngeniería del SoftwareAntonio Navarro
138
Patrones de creaciónBuilder
• Consecuencias- Ventajas
- Permite variar la representación interna de un producto.- Aísla el código de construcción y representación.- Proporciona un control más fino sobre el proceso de construcción.
Ingeniería del SoftwareAntonio Navarro
139
Patrones de creaciónBuilder
• Código de ejemplo- Reinterpretaremos el juego del laberinto desde la óptica del Builder.
Ingeniería del SoftwareAntonio Navarro
140
Patrones de creaciónBuilder
public interface ConstructorLaberinto {public void construirLaberinto();public void construirHabitacion(int habitacion);public void construirPuerta(int puerta);public Laberinto obtenerLaberinto(); }
Ingeniería del SoftwareAntonio Navarro
141
Patrones de creaciónBuilder
public class JuegoDelLaberinto {.........Laberinto crearLaberinto(ConstructorLaberinto
constructor){
constructor.construirLaberinto();constructor.construirHabitacion(1);constructor.construirHabitacion(2);constructor.construirPuerta(1, 2);
return constructor.obtenerLaberinto(); }.........};
Ingeniería del SoftwareAntonio Navarro
142
Patrones de creaciónBuilder
public class ConstructorLaberintoEstandarimplements ConstructorLaberinto {Laberinto laberintoActual;
.........public ConstructorLaberintoEstandar () {laberintoActual = new LaberintoEstandar(); }
public Laberinto obtenerLaberinto(){
return laberintoActual;}
Ingeniería del SoftwareAntonio Navarro
143
Patrones de creaciónBuilder
void construirHabitacion (int n) {
if (laberintoActual.habitacion(n) == null) {
Habitacion h= new HabitacionEstandar(n);laberintoActual.anadirHabitacion(n);h.establecerLado(Norte, new ParedEstandar());h.establecerLado(Sur, new ParedEstandar()); h.establecerLado(Este, new ParedEstandar()); h.establecerLado(Oeste, new ParedEstandar());
}}
Ingeniería del SoftwareAntonio Navarro
144
Patrones de creaciónBuilder
void construirPuerta(int h1, int h2){
Habitacion h1= laberintoActual.habitacion(h1);Habitacion h2= laberintoActual.habitacion(h2);Puerta p= new PuertaEstandar(h1, h2);
h1.establecerLado(Este, p);h2.establecerLado(Oeste, p);
}......... };
Ingeniería del SoftwareAntonio Navarro
145
Patrones de creaciónBuilder
Laberinto laberinto;JuegoDelLaberinto juego = new JuegoDelLaberinto();ConstructorLaberinto constructor = new
ConstructorLaberintoEstandar();
juego.crearLaberinto(constructor);laberinto= constructor.obtenerLaberinto();
Ingeniería del SoftwareAntonio Navarro
146
Patrones de creaciónBuilder
• Nota– Nótese que el Builder también es aplicable
cuando distintas factorías abstractas (a nivel clases que implementan el interfaz) siempre utilizan el mismo mecanismo para crear al objeto que devuelven, puede abstraerse el proceso de creación en un director y utilizar builders para proporcionar los objetos concretos.
Ingeniería del SoftwareAntonio Navarro
147
Patrones de creaciónFactory Method
• Propósito– Define una interfaz para crear un objeto, pero
deja que sean las subclases quienes decidan quéclase instanciar.
– Permite que una clase delegue en sus subclases la creación de objetos.
• También conocido como:– Método de fabricación.– Virtual Constructor (Constructor Virtual)
Ingeniería del SoftwareAntonio Navarro
148
Patrones de creaciónFactory Method
• Motivación- Los marcos usan clases abstractas/interfaces para definir y mantener relaciones entre objetos y también son muchas veces responsables de crear esos mismos objetos.- Por ejemplo, un marco de aplicaciones puede presentar distintos tipos de documentos al usuario.- Una aplicación puede saber cuándo crear un documento, pero no el tipo del mismo.
Ingeniería del SoftwareAntonio Navarro
149
Patrones de creaciónFactory Method
Patrón Factory Method
Ingeniería del SoftwareAntonio Navarro
150
Patrones de creaciónFactory Method
• El patrón FM debe aplicarse cuando:- Una clase no puede prever la clase de objetos que debe crear.- Una clase quiere que sean sus subclases quienes especifiquen los objetos que ésta crea.- Las clases delegan la responsabilidad en una de entre varias clases auxiliares, y queremos localizar en una subclase dicha delegación.
Ingeniería del SoftwareAntonio Navarro
151
Patrones de creaciónFactory Method
• Estructura
Estructura del patrón Factory Method
Ingeniería del SoftwareAntonio Navarro
152
Patrones de creaciónFactory Method
• Consecuencias- Ventajas:
- Elimina la necesidad de ligar nuestro código con clases específicas.
- Inconvenientes:- Los clientes pueden tener que heredar de la clase Creador simplemente para crear un determinado objeto ProductoConcreto.
Ingeniería del SoftwareAntonio Navarro
153
Patrones de creaciónFactory Method
• Código de ejemplo- Reinterpretaremos el juego del laberinto desde la óptica del patrón Factory Method
Ingeniería del SoftwareAntonio Navarro
154
Patrones de creaciónFactory Method
public abstract class JuegoDelLaberinto {........... // atributos del laberintopublic abstract Laberinto fabricarLaberinto();public abstract Habitacion fabricarHabitacion();public abstract Pared fabricarPared();public abstract Puerta fabricarPuerta(Habitacionh1, Habitacion h2);........... // otros métodos del laberinto
};
Ingeniería del SoftwareAntonio Navarro
155
Patrones de creaciónFactory Method
public Laberinto crearLaberinto() {Laberinto l= fabricarLaberinto();Habitacion h1= fabricarHabitacion();Habitacion h2= fabricarHabitacion();Puerta p= fabricarPuerta(h1, h2);
l.anadirHabitacion(h1);l.anadirHabitacion(h2);
Ingeniería del SoftwareAntonio Navarro
156
Patrones de creaciónFactory Method
h1.establecerLado(Norte, fabricarPared());h1.establecerLado(Este, p);h1.establecerLado(Sur, fabricarPared());h1.establecerLado(Oeste, fabricarPared());
h2.establecerLado(Norte, fabricarPared());h2.establecerLado(Este, fabricarPared());h2.establecerLado(Sur, fabricarPared());h2.establecerLado(Oeste, p);
return l; }..........};
Ingeniería del SoftwareAntonio Navarro
157
Patrones de creaciónFactory Method
class JuegoDelLaberintoExplosivo extendsJuegoDelLaberinto {
.........public Pared fabricarPared(){ return new ParedExplosiva(); }
public Habitacion fabricarHabitacion(int n){ return new HabitacionExplosiva(n); }
.........};
Ingeniería del SoftwareAntonio Navarro
158
Patrones de creaciónPrototype
• Propósito– Especifica los tipos de objetos a crear por
medio de una instancia prototípica, y crea nuevos objetos copiando dicho prototipo.
• También conocido como– Prototipo
Ingeniería del SoftwareAntonio Navarro
159
Patrones de creaciónPrototype
• Motivación- Supongamos que deseamos reutilizar un kit de herramientas gráficas.- La reutilización demanda que el uso de los objetos sea independiente de su proceso de creación.
Ingeniería del SoftwareAntonio Navarro
160
Patrones de creaciónPrototype
Patrón prototype
Ingeniería del SoftwareAntonio Navarro
161
Patrones de creaciónPrototype
• El patrón Prototype debe aplicarse cuando:- Las clases a instanciar sean especificadas en tiempo de ejecución.- Para evitar construir una jerarquía de clases fábricas paralela a la jerarquía de clases de los productos.- Cuando las instancias de una clase puedan tener uno de entre sólo unos pocos estados diferentes.
Ingeniería del SoftwareAntonio Navarro
162
Patrones de creaciónPrototype
• Estructura
Estructura del patrón Prototype
Ingeniería del SoftwareAntonio Navarro
163
Patrones de creaciónPrototype
• Consecuencias- Ventajas:
- Similares a las de Abstract Factory y Builder: oculta al cliente las clases producto concretas, reduciendo asíel número de nombres que conocen los clientes y permitiendo que las usen sin cambios. Además permite:- Añadir y eliminar productos en tiempo de ejecución.- Especificar objetos nuevos modificando valores.
Ingeniería del SoftwareAntonio Navarro
164
Patrones de creaciónPrototype
- Especificar nuevos objetos variando la estructura.- Reduce la herencia.- Permite configurar dinámicamente una aplicación con clases, utilizando un gestor de prototipos.
- Inconvenientes- Cada subclase de prototipo debe implementar la operación clonar, lo cual puede ser difícil.
Ingeniería del SoftwareAntonio Navarro
165
Patrones de creaciónPrototype
• Código de ejemplo
public interface FabricaDeLaberintos {public Laberinto hacerLaberinto();public Pared hacerPared();public Habitacion hacerHabitacion();public Puerta hacerPuerta();
};
Ingeniería del SoftwareAntonio Navarro
166
Patrones de creaciónPrototype
public class FabricaDePrototiposLaberintoimplements FabricaDeLaberintos {
Laberinto prototipoLaberinto;Habitacion prototipoHabitación;Pared prototipoPared;Puerta prototipoPuerta;
Ingeniería del SoftwareAntonio Navarro
167
Patrones de creaciónPrototype
FabricaDePrototiposLaberinto(Laberinto l, Pared p, Habitacion h, Puerta pu){
prototipoLaberinto= l;prototipoPared= p;prototipoHabitacion= h;prototipoPuerta= pu;
}
Ingeniería del SoftwareAntonio Navarro
168
Patrones de creaciónPrototype
Pared hacerPared(){ return prototipoPared.clonar(); }
Puerta hacerPuerta(Habitacion h1, Habitacion h2){
Puerta puerta= prototipoPuerta.clonar();puerta.inicializar(h1, h2);return puerta;
}
Ingeniería del SoftwareAntonio Navarro
169
Patrones de creaciónPrototype
JuegoDelLaberinto juego;
FabricaDeLaberintos fabricaDeLaberintosSimples= new FabricaDePrototiposLaberinto(newLaberintoSimple(), new ParedSimple(), newHabitaciónSimple(), new PuertaSimple());
Laberinto l= juego.crearLaberinto(fabricaDeLaberintosSimples);
Ingeniería del SoftwareAntonio Navarro
170
Patrones de creaciónPrototype
public class PuertaSimple implements Puerta {Habitacion h1;Habitacion h2;
public PuertaSimple(Puerta p){ h1= p.h1; h2= p.h2;}
public void inicializar (Habitacion h1P, Habitacionh2P){ h1= h1P; h2= h2P;}
public Puerta clonar(){ return new PuertaSimple(this); }
};
Ingeniería del SoftwareAntonio Navarro
171
Patrones de creaciónPrototype
• Cuestiones- ¿Por qué no hemos definido un interfaz?public interface FabricaDePrototiposLaberintoextends FabricaDeLaberintos {public fijarPrototipos(Laberinto l, Pared p, Habitacion h, Puerta p);
};- ¿Por qué no hemos utilizado la función clone()de Object?
Ingeniería del SoftwareAntonio Navarro
172
Patrones de creaciónPrototype
- ¿Por qué el constructor de PuertaSimplerecibe una Puerta como parámetro, si al final, la factoría tiene que inicializarla? Es decir, ¿por quéno tenemos lo siguiente?
public class PuertaSimple implements Puerta {
public Puerta clonar(){ return new PuertaSimple(); }
}
Ingeniería del SoftwareAntonio Navarro
173
Patrones de creaciónSingleton
• Propósito– Garantiza que una clase solo tenga una
instancia, y proporciona un punto de acceso global a ella.
• Tambien conocido como– Único.
Ingeniería del SoftwareAntonio Navarro
174
Patrones de creaciónSingleton
• Motivación- Es importante que algunas clases solo tengan una instancia, e.g. cola de impresión, biblioteca, etc.- ¿Cómo garantizamos que una clase tenga una única instancia fácilmente accesible?- La propia clase es responsable de su única instancia.
Ingeniería del SoftwareAntonio Navarro
175
Patrones de creaciónSingleton
• El patrón Singleton debe aplicarse cuando:- Debe haber exactamente una instancia de clase, y ésta debe ser accesible a los clientes desde un punto de acceso conocido.- La única instancia debería ser extensible mediante herencia, y los clientes deberían ser capaces de usar una instancia extendida sin modificar su código.
Ingeniería del SoftwareAntonio Navarro
176
Patrones de creaciónSingleton
• Estructura
Estructura del patrón Singleton
Ingeniería del SoftwareAntonio Navarro
177
Patrones de creaciónSingleton
• Consecuencias- Ventajas
- Acceso controlado a la única instancia.- Espacio de nombres reducido.- Permite el refinamiento de operaciones y la representación.- Permite un número variable de instancias.- Más flexibles que las operaciones de clase estáticas.
Ingeniería del SoftwareAntonio Navarro
178
Patrones de creaciónSingleton
• Código de ejemploclass FabricaDeLaberintosEncantados implements
FabricaDeLaberintos {private static FabricaDeLaberintosEncantadosfabrica;
public static FabricaDeLaberintosobtenerInstancia(){ if (fabrica == null) fabrica= new
FabricaDeLaberintosEncantados(); return fabrica;
}......... }
Ingeniería del SoftwareAntonio Navarro
179
Patrones estructuralesAdapter
• Propósito– Convierte 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 tener interfaces compatibles.• También conocido cómo
– Adaptador.– Wrapper (Envoltorio).
Ingeniería del SoftwareAntonio Navarro
180
Patrones estructuralesAdapter
• Motivación– A veces una clase de toolkit que ha sido
diseñada para reutilizarse, no puede hacerlo porque su interfaz no coincide con la interfaz específica del dominio que requiere la aplicación.
– Por eso es necesario adaptarla para que pueda ser utilizada
Ingeniería del SoftwareAntonio Navarro
181
Patrones estructuralesAdapter
Patrón Adapter
Ingeniería del SoftwareAntonio Navarro
182
Patrones estructuralesAdapter
• El patrón Adapter debe aplicarse cuando- Se quiere usar una clase existente y su interfaz no concuerda con la que se necesita.- Se quiere crear una clase reutilizable que coopere con clases no relacionadas o que no han sido previstas, es decir, clases que no tiene por quétener interfaces compatibles.
Ingeniería del SoftwareAntonio Navarro
183
Patrones estructuralesAdapter
- (en el caso de un adaptador de objetos) es necesario usar varias subclases existentes, pero no resulta práctico adaptar su interfaz heredando de cada una de ellas. Un adaptador de objetos puede adaptar la interfaz de su clase padre.
Ingeniería del SoftwareAntonio Navarro
184
Patrones estructuralesAdapter
• Estructura
Estructura de un Adaptador de Clases
Ingeniería del SoftwareAntonio Navarro
185
Patrones estructuralesAdapter
Estructura de un Adaptador de objetos
Ingeniería del SoftwareAntonio Navarro
186
Patrones estructuralesAdapter
• Consecuencias adaptador clases- Ventajas
- Permite que el adaptador redefina parte del comportamiento del adaptable, al ser subclase suya.- Introduce un solo objeto, y no se necesita ningún puntero de indirección adicional para obtener el objeto adaptado.
- Inconvenientes- La adaptación es de una clase, pero no de sus subclases.
Ingeniería del SoftwareAntonio Navarro
187
Patrones estructuralesAdapter
• Consecuencias adaptador objetos- Ventajas:
- Permite que un adaptador funcione con muchos adaptables, es decir, con sus subclases. Además, el adaptador puede añadir funcionalidad a todos los adaptables.
- Inconvenientes:- Obliga a vincular al adaptador a las clases que pudieran aparecer del adaptable.
Ingeniería del SoftwareAntonio Navarro
188
Patrones estructuralesAdapter
• Código de ejemplo (objetos)
public interface IED {public int insertar(Comparable objetoP);public int eliminar(Object idObjeto);public Comparable obtenerPorId(Object idObjeto); public Comparable obtenerPorPos(int pos);public int obtenerNumEletos();
};
Ingeniería del SoftwareAntonio Navarro
189
Patrones estructuralesAdapter
public class DynamicList {public int insert(Comparable objectP) {...};public int delete(Object idObject) {...};public Comparable getById(Object idObject) {...}; public Comparable getByPos(int pos) {...};public int getNumElements() {...};
};
Ingeniería del SoftwareAntonio Navarro
190
Patrones estructuralesAdapter
public class ListaDinamica implements IED {DynamicList lista;
ListaDinamica (){ lista= new DynamicList(); }
public int insertar(Object o){ return lista.insert(o); }.........};
Ingeniería del SoftwareAntonio Navarro
191
Patrones estructuralesAdapter
• Código de ejemplo (clases)
public class ListaDinamica extends DynamicListimplements IED {
public int insertar(Object o){ return insert(o); }.........};
Ingeniería del SoftwareAntonio Navarro
192
Patrones estructuralesBridge
• Propósito– Desacopla una abstracción de su
implementación, de modo que ambas puedan variar de forma independiente.
• También conocido cómo– Puente– Handle/Body (Manejador/Cuerpo)
Ingeniería del SoftwareAntonio Navarro
193
Patrones estructuralesBridge
• Motivación– Cuando una abstracción (clase abstracta) puede
tener varias implementaciones posibles, la forma más habitual de darle cabida es mediante la herencia.
– La herencia liga las implementaciones a las abstracciones.
Ingeniería del SoftwareAntonio Navarro
194
Patrones estructuralesBridge
Duplicación de jerarquía de implementaciones al ligarla a la jerarquía de abstracciones
Ingeniería del SoftwareAntonio Navarro
195
Patrones estructuralesBridge
El patrón BridgeIngeniería del SoftwareAntonio Navarro
196
Patrones estructuralesBridge
• El patrón Bridge debe aplicarse cuando- Se quiera evitar un enlace permanente entre una abstracción y su implementación (e.g. cuando deba seleccionarse o cambiarse en tiempo de ejecución).- Tanto las abstracciones como sus implementaciones deban ser extensibles mediante subclases y de manera independiente.
Ingeniería del SoftwareAntonio Navarro
197
Patrones estructuralesBridge
- Los cambios en la implementación de una abstracción no deberían tener impacto en los clientes, es decir, no es necesario recompilar su código (alternativa a las factorías abstractas).- Se pretenda ocultar completamente a los clientes la implementación (atributos) de una abstracción (C++).- Se quiera evitar una proliferación de clases de implementación que duplica la estructura de herencia de las abstracciones.
Ingeniería del SoftwareAntonio Navarro
198
Patrones estructuralesBridge
- Se quiera compartir una implementación entre varios objetos y este hecho deba permanecer oculto al cliente (también se podría resolver con factorías que producen Singletons).
Ingeniería del SoftwareAntonio Navarro
199
Patrones estructuralesBridge
• Estructura
Estructura del patrón Bridge
Ingeniería del SoftwareAntonio Navarro
200
Patrones estructuralesBridge
• Consecuencias- Ventajas
- Desacopla la interfaz de la implementación, permitiendo cambios en ejecución y evitando dependencias de compilación.- Mejora la extensibilidad al independizar las jerarquías de abstracciones e implementaciones.- Oculta detalles de implementación a los clientes, como el compartir objetos de implementación.
Ingeniería del SoftwareAntonio Navarro
201
Patrones estructuralesBridge
• Código de ejemplopublic class Ventana {
//peticiones manejadas por la ventanapublic void DibujarContenido();public void Abrir();public void Cerrar();public void Minimizar();public void Maximizar();
Ingeniería del SoftwareAntonio Navarro
202
Patrones estructuralesBridge
//peticiones reenviadas a su implementaciónpublic void EstablecerOrigen(Punto en) {...};public void EstablecerArea (Punto area) {...};public void TraerAlFrente() {...};public void EnviarAlFondo() {...};
public void DibujarLinea(Punto p1, Punto p2) {...};public void DibujarRect(Punto p1, Punto p2) {...};public void DibujarPoligono(Punto []pts, int n) {...};public void DibujarTexto(String s, Punto p) {...};
Ingeniería del SoftwareAntonio Navarro
203
Patrones estructuralesBridge
protected VentanaImp obtenerVentanaImp() {...};protected Vista obtenerVista() {...};
VentanaImp imp;Vista contenido; //el contenido de la ventana};
Ingeniería del SoftwareAntonio Navarro
204
Patrones estructuralesBridge
public interface VentanaImp {public void ImpSuperior();public void ImpInferior();public void ImpEstablecerArea(Punto p);public void ImpEstablecerOrigen(Punto p);
public void DispositivoRect(Coord c1, Coord c2, Coord c3, Coord c4);public void DispositivoTexto(String s, Coordc1, Coord c2);
//resto de funciones para dibujar en ventanas};
Ingeniería del SoftwareAntonio Navarro
205
Patrones estructuralesBridge
class VentanaAplicacion extends Ventana {............
public void dibujarContenido(){
obtenerVista().dibujarEn(this); }
};
Ingeniería del SoftwareAntonio Navarro
206
Patrones estructuralesBridge
class VentanaIcono extends Ventana {.........
String nombreMapaDeBits;public void dibujarContenido(){
VentanaImp imp= obtenerVentanaImp();if (imp != null) {
imp.dispositivoMapaDeBits(nombreMapaDeBits, 0, 0);
}}
};
Ingeniería del SoftwareAntonio Navarro
207
Patrones estructuralesBridge
public class VentanaSencilla implementsVentanaImp{
.........};
public class VentanaCalidad implements VentanaImp{
.........};
Ingeniería del SoftwareAntonio Navarro
208
Patrones estructuralesBridge
• ¿Cómo se implementa el patrón Bridge si las abstracciones son interfaces, y no clases?
• Nótese que sin la presencia de las clases que refinan a la abstracción, el patrón bridge se queda en delegar en un objeto visto a través de un interfaz, en vez de delegar en subclases. Es algo así como delegar en subclases para crear (factory method) o delegar en objetos (abstract factory).
Ingeniería del SoftwareAntonio Navarro
209
Patrones estructuralesBridge
El patrón bridge con una clase que refina a la abstracciónBridge pasa de (i) a (ii)(i)
(ii)
Bg()
A<<abstract>>
f()
IImpA<<Interface>>
f1()f2()f3()g1()g2()
Imp1 Imp2
Bg()
Imp2Af()
Imp1Bg()
Imp2Bg()
Imp1Af()
Af()
<<abstract>>
f() utiliza a f1(), f2() y f3() para su implementacióng() utiliza a g1() y g2() para su implementación
Ingeniería del SoftwareAntonio Navarro
210
Patrones estructuralesBridge
Imp2Af()
Imp1Af()
Af()
<<abstract>>A
f()
<<abstract>> IImpAf1()f2()f3()
<<Interface>>
Imp1 Imp2
f() uti liza a f1(), f2() y f3() para su implementación
El patrón bridge sin una clase que refine a la abstracción(i) (ii)
bridge pasa de (i) a (ii)
Ingeniería del SoftwareAntonio Navarro
211
Patrones estructuralesComposite
• Propósito– Compone objetos en estructuras de árbol para
representar jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a los objetos individuales y a los compuestos.
• También conocido como– Compuesto.
Ingeniería del SoftwareAntonio Navarro
212
Patrones estructuralesComposite
• Motivación– Las aplicaciones gráficas como los editores de
dibujo permiten a los usuarios construir diagramas complejos a partir de componentes simples.
– El código que usa estas clases debe tratar de forma diferente a los objetos primitivos y a los contenedores, aunque se traten de forma idéntica.
Ingeniería del SoftwareAntonio Navarro
213
Patrones estructuralesComposite
El patrón Composite
Ingeniería del SoftwareAntonio Navarro
214
Patrones estructuralesComposite
Objetos compuestos
Ingeniería del SoftwareAntonio Navarro
215
Patrones estructuralesComposite
• El patrón Composite debe aplicarse cuando- Se quiera representar jerarquías de objetos parte-todo.- Se quiera que los clientes sean capaces de obviar las diferencias entre composiciones de objetos y los objetos individuales. Los clientes tratarán a todos los objetos de la estructura compuesta de manera uniforme.
Ingeniería del SoftwareAntonio Navarro
216
Patrones estructuralesComposite
• Estructura
Estructura del patrón Composite
Ingeniería del SoftwareAntonio Navarro
217
Patrones estructuralesComposite
Estructura de objetos compuestos
Ingeniería del SoftwareAntonio Navarro
218
Patrones estructuralesComposite
• Consecuencias- Ventajas
- Define jerarquías de clases formadas por objetos primitivos y compuestos.
- Permite un tratamiento uniforme por parte del cliente.
- Facilita añadir nuevos tipos de componentes.
- Inconvenientes- Oculta los tipos de los objetos dentro del compuesto.
Ingeniería del SoftwareAntonio Navarro
219
Patrones estructuralesComposite
• Código de ejemplopublic interface IEquipo {
public String Nombre();
float Potencia();float precioNeto();float precioDescuento();
Ingeniería del SoftwareAntonio Navarro
220
Patrones estructuralesComposite
public void anadir(Equipo e);public void eliminar(Equipo e);public Iterador crearIterador();
};
public class Disquetera implements Equipo {.........};
Ingeniería del SoftwareAntonio Navarro
221
Patrones estructuralesComposite
public class Equipo implements IEquipo {String nombre;Lista listaIEquipo;
float precioNeto(){ Iterador i= crearIterador();
float total= 0;for (i.primero; !i.haTerminado(); i.siguiente())
total += i.elementoActual().precioNeto();return total;
}
Ingeniería del SoftwareAntonio Navarro
222
Patrones estructuralesDecorator
• Propósito– Asigna responsabilidades adicionales a un
objeto dinámicamente, proporcionando una alternativa flexible a la herencia para extender la funcionalidad.
• También conocido como– Decorador.– Wrapper (envoltorio).
Ingeniería del SoftwareAntonio Navarro
223
Patrones estructuralesDecorator
• Motivación– A veces queremos añadir responsabilidades a
objetos individuales en vez de a toda una clase.– Por ejemplo, los bordes o desplazamientos
asociados a componentes de una IGU.– La herencia es una solución estática.– Un enfoque más flexible es encerrar el
componente en otro objeto que añada el borde.– Así, podemos seguir una aproximación recursiva.
Ingeniería del SoftwareAntonio Navarro
224
Patrones estructuralesDecorator
Composición de decoradores
Ingeniería del SoftwareAntonio Navarro
225
Patrones estructuralesDecorator
El patrón DecoratorIngeniería del SoftwareAntonio Navarro
226
Patrones estructuralesDecorator
• El patrón Decorator debe aplicarse cuando- Se desee añadir objetos individuales de forma dinámica y transparente, es decir, sin afectar a otros objetos.- Se desee la posibilidad de eliminar responsabilidades.- Cuando la extensión mediante herencia no es viable por la explosión de subclases que se producen.
Ingeniería del SoftwareAntonio Navarro
227
Patrones estructuralesDecorator
• Estructura
Estructura del patrón DecoratorIngeniería del SoftwareAntonio Navarro
228
Patrones estructuralesDecorator
• Consecuencias- Ventajas
- Más flexibilidad que la herencia múltiple estática.- Evita clases cargadas con funciones en la parte de arriba de la jerarquía, ya que pueden añadirse en el decorador.
- Inconvenientes- Un decorador y su componente no son idénticos.- Aparecen muchos objetos pequeños.
Ingeniería del SoftwareAntonio Navarro
229
Patrones estructuralesDecorator
• Código de ejemplopublic interface ComponenteVisual {
public void dibujar();public void cambiarTamano();
};
Ingeniería del SoftwareAntonio Navarro
230
Patrones estructuralesDecorator
class Decorador implements ComponenteVisual {ComponenteVisual componente;
public Decorador(ComponenteVisual c){ componente= c; }
public void dibujar(){ componente.dibujar(); }
public void cambiarTamano(){ componente.cambiarTamano(); }
};
Ingeniería del SoftwareAntonio Navarro
231
Patrones estructuralesDecorator
public class DecoradorBorde extends Decorator {int anchoBorde;
public DecoradorBorde(ComponenteVisual c, int a){ super(c); anchoBorde= a; }
private void dibujarBorde(int ancho) {...};
public void dibujar(){super.dibujar();dibujarBorde(anchoBorde);
}};
Ingeniería del SoftwareAntonio Navarro
232
Patrones estructuralesDecorator
• Discusión: en el ejemplo anterior, la clase Decorador es imprescindible?
• ¿Cuándo es imprescindible la clase Decorador?
Ingeniería del SoftwareAntonio Navarro
233
Patrones estructuralesFacade
• Propósito– Proporciona una interfaz unificada para un
conjunto de interfaces de un subsistema. Define una interfaz de alto nivel que hace que el subsistema sea más fácil de usar.
• También conocido como– Fachada.
Ingeniería del SoftwareAntonio Navarro
234
Patrones estructuralesFacade
• Motivación– Estructurar un sistema en subsistemas ayuda a
reducir la complejidad.– Un objetivo clásico en diseño es minimizar la
comunicación y dependencias entre subsistemas.– Un modo de lograr esto es introduciendo un
objeto fachada que proporcione una interfaz única y simplificada para los servicios más generales del subsistema.
Ingeniería del SoftwareAntonio Navarro
235
Patrones estructuralesFacade
El patrón Facade
Ingeniería del SoftwareAntonio Navarro
236
Patrones estructuralesFacade
• El patrón Facade debe aplicarse cuando- Queramos proporcionar una interfaz simple para un subsistema complejo.- Haya muchas dependencias entre los clientes y las clases que implementan una abstracción.- Queramos dividir en capas nuestros subsistemas.
Ingeniería del SoftwareAntonio Navarro
237
Patrones estructuralesFacade
• Consecuencias- Ventajas
- Oculta a los clientes los componentes del subsistema, reduciendo así el número de objetos con los que traten los clientes y haciendo que el subsistema sea más fácil de usar.- Promueve un débil acoplamiento entre el subsistema y los clientes.- No impide que las aplicaciones utilicen clases del subsistema si es necesario.
Ingeniería del SoftwareAntonio Navarro
238
Patrones estructuralesFacade
• Código de ejemplopublic class Biblioteca implements IBiblioteca {
IEjemplares ejemplares;IUsuarios usuarios;IInterfazBiblioteca interfazBiblioteca;
public Biblioteca(IFactoriaBiblioteca factoriaBiblioteca) { ejemplares= factoriaBiblioteca.generarEjemplares();
usuarios= factoriaBiblioteca.generarUsuarios();}
Ingeniería del SoftwareAntonio Navarro
239
Patrones estructuralesFacade
public void insertarLibro(String nombre, String autor){ ejemplares.insertarLibro(nombre, autor); }
public void insertarRevista(String nombre, int volumen, int numero){ ejemplares.insertarRevista(nombre, volumen ,numero); }
.........public void insertarUsuario(String nombre){ usuarios.insertarUsuario(nombre); }
.........};
Ingeniería del SoftwareAntonio Navarro
240
Patrones estructuralesFlyweight
• Propósito– Usa compartición para permitir un gran número
de objetos de grano fino de forma eficiente.• También conocido como
– Peso ligero
Ingeniería del SoftwareAntonio Navarro
241
Patrones estructuralesFlyweight
• Motivación- Utilizar copias de objetos para todo es muy costoso en recursos e integridad.- Por ejemplo, los caracteres de un documento.- El patrón Flyweight describe cómo compartir objetos para permitir su uso con granularidadesmuy finas, sin un coste prohibitivo.
Ingeniería del SoftwareAntonio Navarro
242
Patrones estructuralesFlyweight
- Un peso ligero es un objeto compartido que puede usarse a la vez en varios contextos.- El peso ligero es un objeto independiente en cada contexto, no se puede distinguir de una instancia del objeto que no esté compartida.- Los pesos ligeros no pueden hacer suposiciones sobre el contexto en el cual operan.- Lo fundamental es la distinción entre estado intrínseco y extrínseco.
Ingeniería del SoftwareAntonio Navarro
243
Patrones estructuralesFlyweight
- El estado intrínseco se guarda en el propio objeto. Consisten en información que es independiente de su contexto y que puede ser compartida.- El estado extrínseco depende del contexto y cambia con él, por lo que no puede ser compartido.- Los objetos cliente son responsables de pasar al peso ligero su estado extrínseco cuando lo necesite.
Ingeniería del SoftwareAntonio Navarro
244
Patrones estructuralesFlyweight
El patrón Flyweight
Ingeniería del SoftwareAntonio Navarro
245
Patrones estructuralesFlyweight
Patrón FlyweightIngeniería del SoftwareAntonio Navarro
246
Patrones estructuralesFlyweight
El patrón Flyweight
Ingeniería del SoftwareAntonio Navarro
247
Patrones estructuralesFlyweight
• El patrón Flyweight debe aplicarse cuando- Una aplicación utilice un gran número de objetos, y- Los costes de almacenamiento sean elevados debido a la gran cantidad de objetos, y- La mayor parte del estado del objeto pueda hacerse extrínseco, y
Ingeniería del SoftwareAntonio Navarro
248
Patrones estructuralesFlyweight
- Muchos grupos de objetos puedan reemplazarse por relativamente pocos objetos compartidos, una vez que se ha eliminado el estado extrínseco, y- La aplicación no depende de la identidad de un objeto. Puesto que los objetos peso ligero pueden ser compartidos, las comprobaciones de identidad devolverán verdadero para objetos conceptualmente distintos.
Ingeniería del SoftwareAntonio Navarro
249
Patrones estructuralesFlyweight
• Estructura
Estructura de Flyweight Ingeniería del SoftwareAntonio Navarro
250
Patrones estructuralesFlyweight
• Consecuencias- Ventajas
- Ahorro de almacenamiento.- Integridad.
- Inconvenientes- Costes de tiempo de ejecución.
Ingeniería del SoftwareAntonio Navarro
251
Patrones estructuralesFlyweight
• Código de ejemplopublic interface Glifo {
public void dibujar(Ventana v, ContextoGlifo cg);public void establecerFuente(Fuente f, ContextoGlifocg);public void obtenerFuente(ContextoGlifo cg);public void primero(ContextoGlifo cg);public void siguiente(ContextoGlifo cg);public Boolean haTerminado(ContextoGlifo cg);public Glifo actual(ContextoGlifo cg);public void insertar(Glifo g, ContextoGlifo cg);public void borrar(ContextoGlifo cg); };
Ingeniería del SoftwareAntonio Navarro
252
Patrones estructuralesFlyweight
public Class Caracter implements Glifo {char codigoCaracter;
public Carácter(char c){ codigoCaracter= c; }
public void Dibujar(Ventana v, ContextoGlifo cg) {...};
};
Ingeniería del SoftwareAntonio Navarro
253
Patrones estructuralesFlyweight
class ContextoGlifo {int indice;Arbol fuentes;public ContextoGlifo() {...};public void siguiente(int incremento)
{indice += incremento};public void insertar (int cantidad) {...};public Fuente obtenerFuente();public void establecerFuente(Fuente f, int
extension) {...}; };
Ingeniería del SoftwareAntonio Navarro
254
Patrones estructuralesFlyweight
Texto
Ingeniería del SoftwareAntonio Navarro
255
Patrones estructuralesFlyweight
Representación del Contexto para el texto anteriorIngeniería del SoftwareAntonio Navarro
256
Patrones estructuralesFlyweight
Si en el indice 102 queremos que expect sea Times Roman de 12 ptos:
Fuente times12= new Fuente (“Times-Roman-12”);Fuente timesItalic12= new Fuente(“Times-Italic-12”);.........contextoGlifo.establecerFuente(times12, 6);
Ingeniería del SoftwareAntonio Navarro
257
Patrones estructuralesFlyweight
Nuevo estado del contextoIngeniería del SoftwareAntonio Navarro
258
Patrones estructuralesFlyweight
Si deseamos añadir la palabra don´t (con el espacio en blanco) en Times Italic de 12 puntos, antes de expect, y suponiendo que estemos en el indice102:
contextoGlifo.insertar(6);contextoGlifo.establecerFuente(timesItalic12, 6);
Ingeniería del SoftwareAntonio Navarro
259
Patrones estructuralesFlyweight
Nuevo estado del contextoIngeniería del SoftwareAntonio Navarro
260
Patrones estructuralesFlyweight
public class FabricaDeGlifos {int NCODIGOSC= 128;Caracter caracter[NCODIGOSC];
public FabricaDeGlifos(){ for (int i= 0; i<NCODIGOSC; i++)
caracter[i]= null; }
public Caracter crearCaracter(char c){ if (caracter[c] == null) caracter[c]=
new Caracter(c);return caracter[c]; }
Ingeniería del SoftwareAntonio Navarro
261
Patrones estructuralesFlyweight
public Fila crearFila(){ return new Fila(); }
public Columna crearColumna(){ return new Columna(); }
.........};
Ingeniería del SoftwareAntonio Navarro
262
Patrones estructuralesProxy
• Propósito– Proporciona un representante o sustituto de otro
objeto para controlar el acceso a éste.• También conocido como
– Apoderado.– Surrogate (Sustituto).
Ingeniería del SoftwareAntonio Navarro
263
Patrones estructuralesProxy
• Motivación– Una razón para controlar el acceso a un objeto
es retrasar todo el coste de su creación e inicialización hasta que sea realmente necesario usarlo.
– Por ejemplo, en el contexto de recuperar varios objetos de un archivo.
– Por ejemplo, para manejar imágenes en un procesador de textos.
Ingeniería del SoftwareAntonio Navarro
264
Patrones estructuralesProxy
Un cliente de un Proxy
Ingeniería del SoftwareAntonio Navarro
265
Patrones estructuralesProxy
El patrón ProxyIngeniería del SoftwareAntonio Navarro
266
Patrones estructuralesProxy
• El patrón Proxy debe aplicarse cuando- Hay necesidad de una referencia a un objeto más versátil o sofisticada que un simple puntero.- Tipos de Proxy:
- Remoto. Proporicona un representante local de un objeto situado en otro espacio de direcciones.- Virtual. Crea objetos costosos por encargo.- De protección. controla el acceso al objeto original.
Ingeniería del SoftwareAntonio Navarro
267
Patrones estructuralesProxy
- Referencia inteligente. Es un sustituto de un simple puntero que lleva a cabo operaciones adicionales cuando se accede a un objeto. Por ejemplo:- Contar el número de referencias al objeto real de forma que éste pueda liberarse automáticamente cuando no haya ninguna referencia apuntándole (punteros inteligentes).- Cargar un objeto persistente en la memoria cuando es referenciado por primera vez.- Comprobar que se bloquea el objeto real antes de acceder a él para garantizar que no pueda ser modificado por ningún otro objeto.
Ingeniería del SoftwareAntonio Navarro
268
Patrones estructuralesProxy
• Estructura
Estructura del patrón Proxy
Ingeniería del SoftwareAntonio Navarro
269
Patrones estructuralesProxy
Objetos según el patrón Proxy
Ingeniería del SoftwareAntonio Navarro
270
Patrones estructuralesProxy
• Consecuencias- Ventajas
- Un proxy remoto oculta el hecho de residir en un espacio de direcciones diferente.- Un proxy virtual puede llevar a cabo optimizaciones tales como crear objetos por encargo.- Un proxy de protección, permite realizar tareas adicionales cuando se accede a un objeto.- Copia de escritura, solo da copias a clientes que puedan modificar el objeto.
Ingeniería del SoftwareAntonio Navarro
271
Patrones estructuralesProxy
• Código de ejemplo (proxy virtual)public interface Grafico extends Serializable {
public void dibujar(Punto en);public void manejarRaton(Evento e);public Punto obtenerExtension();
};
Ingeniería del SoftwareAntonio Navarro
272
Patrones estructuralesProxy
public class Imagen implements Grafico {Imagen(String fichero) {...};public void dibujar(Punto en) {...};
public void manejarRaton(Evento e) {...};public Punto obtenerExtension() {...};
.........};
Ingeniería del SoftwareAntonio Navarro
273
Patrones estructuralesProxy
public class ProxyImagen implements Grafico {Imagen imagen;Punto extension;String nombreFichero;
public ProxyImagen(String nombreFicheroP){ nombreFichero= nombreFicheroP;
extension= null;imagen= null;
}
Ingeniería del SoftwareAntonio Navarro
274
Patrones estructuralesProxy
protected Imagen obtenerImagen(){ if (imagen==null) imagen= new Imagen(nombreFichero);
return imagen; }
public Punto obtenerExtension(){ if (imagen==null)
extension= obtenerImagen().obtenerExtension();return extension;
}
Ingeniería del SoftwareAntonio Navarro
275
Patrones estructuralesProxy
public void dibujar (Punto en){ obtenerImagen().dibujarEn(); }
public void manejarRaton(Evento e){ obtenerImagen().manejarRaton(e); }
Ingeniería del SoftwareAntonio Navarro
276
Patrones estructuralesProxy
public class DocumentoDeTexto {.........public void insertar(Grafico g) {...};.........};
DocumentoDeTexto texto= new DocumentoDeTexto();texto.insertar(new
ProxyImagen(“nombreFicheroImagen”));
Top Related