introducción a los patrones de diseño
TRANSCRIPT
1
Departamento deDepartamento de
Lenguajes y Sistemas InformLenguajes y Sistemas Informááticosticos
escuela técnica superior
de ingeniería informática
Introducción a los Patrones de Diseño
Ingeniería del Software II
El Camino
♦ Qué es un Patrón de Diseño (PD)
♦ Qué no es un PD
2
Qué es un Patrón de Diseño
♦ ¿Qué es el diseño?¿Qué es un patrón? ¿Qué es un patrón de diseño?
♦ El diseño es una actividad
♦ El cómo frente al qué
♦ Hacerlo correcto frente a hacer lo correcto
♦ Asignar responsabilidades a las clases
♦ ¿Es una actividad difícil?
♦ Debe serlo pues está bien remunerada
♦ “Un martillo no te hace un buen arquitecto”. Conocer un lenguaje OO no te hace un buen diseñador (aunque es imprescindible)
♦ Los requisitos no funcionales son “conflictivos”
Qué es un Patrón de Diseño
♦ Por lo tanto el diseñador debe …
♦ Encontrar una solución que consiga el equilibrio óptimo entre las propiedades no funcionales
♦Si damos el mismo documento de requisitos a 10 diseñadores, obtendremos 10 diseños diferentes
♦ ¿Qué diferencia hay entre los diseñadores expertos y los novatos?
♦ Recetas para los problemas habituales. No están reinventando la rueda continuamente
♦ Utilizan recetas exitosas
♦ ¿Cómo se describen estas recetas?
3
Qué es un Patrón de Diseño
♦ Orígenes de los PP.DD
♦ Definiciones
♦ Clasificación
♦ Ejemplo: PD Singleton
Qué es un Patrón de Diseño
� Orígenes de los PP.DD
♦ Definiciones
♦ Clasificación
♦ Ejemplo: PD Singleton
4
Qué es un PDOrígenes de los PP.DD
♦ Christopher Alexander (Viena, 1936)
1977
1979
Qué es un PDOrígenes de los PP.DD
Kent BeckWardCunnighan
1. Window per Task
2. Few Panes
3. Standard Panes
4. Nouns and Verbs
5. Short Menus
OOPSLA 87
5
Qué es un PDOrígenes de los PP.DD
♦ 1990. Erich Gamma asiste a una charla de Bruce Andersen en un taller del OOPSLA, titulada “Architecture Handbook”. Esta realizando su tesis doctoral y necesita desarrollar un Framework C++ para aplicaciones gráficas multiplataforma (ET++)
RalphJohnson
JohnVlissides
Richard Helm
♦1991. Andersen organiza un taller donde Gamma coincide con:
Qué es un PDOrígenes de los PP.DD
♦ 1993. Beck y Booch “sufragan” un retiro en las montañas de colorado. Nace el HillSide
♦1994. Hillside organiza la primera edición del PLOP
(Patterns Languages of Program Design). La banda
de los cuatro venden más de 750 ejemplares de su
libro (10 veces más que cualquier libro hasta
entonces)
6
Qué es un PDOrígenes de los PP.DD
Lecciones aprendidas
♦ Los PP.DD han surgido tomando ideas de otras disciplinas (la arquitectura las toma a su vez de la Biología)
♦ Los PP.DD han tenido su origen en la Academia y no en la industria (es de los pocos ejemplos)
♦ Las tesis doctorales sirven para algo
♦ El mundo anglosajón suele hacer un uso intensivo de los grupos de presión en todos los ámbitos
♦ Orígenes de los PP.DD
� Definiciones
♦ Clasificación
♦ Ejemplo: PD Singleton
Qué es un PD
7
♦De manera general
Qué es un PDDefiniciones
Patrón de diseño: Una solución
general a un problema general
que puede adaptarse a un
problema concreto
http://www.textile-creation-club.com/esp/patrones.htm
Patrón: Modelo que sirve de
muestra para sacar otra cosa
igual (RAE)
♦ En Arquitectura
Qué es un PDDefiniciones
Cada patrón describe un problema que ocurre
una y otra vez en nuestro entorno. También
describe el núcleo de la solución al problema, de
forma que puede utilizarse un millón de veces
sin hacer dos veces lo mismo
• Técnica de descripción
• Par problema-solución
• Recurrente
• Sólo el núcleo, no es una solución completa
• Reutilizable
8
♦ En Ingeniería del Software (Gamma95, pág. 360)
Qué es un PDDefiniciones
A design pattern systematically names, motivates,
and explains a general design that addresses a
recurring design problem in OO systems.
It describes the problem, the solution, when to
apply the solution, and its consequences. It also
gives implementation hints and examples.
The solution is a general arrangement of object and
classes that solve the problem. The solution is
customized and implemented to solve the problem
in a particular context.
♦ En Ingeniería del Software (Larman, pag. 204)
♦ Existe consenso en:
♦ Par (problema, solución)
♦ Reutilizar conocimiento vs reutilizar software
♦ Problemas recurrentes (¿Cuándo se considera recurrente?)
Qué es un PDDefiniciones
Un patrón es un par problema/solución con nombre
que se puede aplicar en nuevos contextos con
consejos acerca de cómo aplicarlo en nuevas
situaciones y discusiones sobre sus compromisos
9
♦ Orígenes de los PP.DD
♦ Definiciones
� Clasificación
♦ Ejemplo: PD Singleton
Qué es un PD
ClasificaciónPlantilla de descripción de la GoF
1. Nombre y clasificación: expresa sucintamente la esencia del patrón
2. Intención: frase corta que responde a qué hace y qué resuelve
3. También conocido como: otros nombres conocidos para el PD
4. Motivación: un escenario que ilustra como el PD resuelve un problema concreto
5. Aplicabilidad: otras situaciones en las que resulta aplicable el PD
6. Estructura: diagramas de clases
7. Participantes: responsabilidad de cada clase participante
8. Colaboraciones: diagrama de colaboración y/o de secuencias
9. Consecuencias: ventajas e inconvenientes
10.Implementación: dificultades, técnicas y trucos a tener en cuenta al aplicar el PD
11.Código de ejemplo: ejemplo de implementación y de uso del PD
12.Usos conocidos: ejemplos de uso en sistemas reales
13.Patrones relacionados: diferencias con los patrones más relacionados
10
Cadena de Responsabilidad, Comando,
Iterador, Mediador, Memento,
Observador, Estado, Estrategia, Visitante,
Método Plantilla
De Comportamiento
Adaptador, Puente, Compuesto, Decorador,
Fachada, Peso Mosca, Apoderado
Estructural
Fábrica Abstracta, Método Fábrica,
Constructor, Prototipo, Singular
Creacional
ClasificaciónCatálogo de la GoF
Clasificación Relaciones entre patrones
11
ClasificaciónCatálogo de Grand
♦ Parte de la de Gamma y la extiende con 9 categorías más:
♦ Fundamentales
♦ Particionamiento
♦ Concurrencia
♦ GRASP
♦ GUI
♦ Organización del código
♦ Optimización del código
♦ Robustez
♦ Prueba
♦ Orígenes de los PP.DD
♦ Definiciones
♦ Clasificación
� Ejemplo: PD Singleton
Qué es un PD
12
Facade
1. Nombre/Clasificación: Facade (Fachada). Estructural.
2. Intención: Proporcionar una interfaz unificada para un conjunto de interfaces en un subsistema, haciéndolo más fácil de usar
3. Motivación: Reducir la complejidad y minimizar dependencias
clases clientes
clases del subsistema
FachadaFachada
Facade
♦ Motivación
♦ Estructurar un entorno de programación
CompiladorCompilador
Clases del
subsistema de
compilación
Clases del
subsistema de
compilación
EditorEditor
DepuradorDepurador
LinkadorLinkador
TokenToken
AnaLexAnaLex
AnaSinAnaSin
ASAASA TabSim
TabSim
Compilar()Compilar()
13
Facade
4) Aplicabilidad:
♦ Se quiera proporcionar una interfaz sencilla para un subsistema complejo
♦ Se quiera desacoplar un subsistema de sus clientes y de otros subsistemas, haciéndolo mas independiente y portable
♦ Se quiera dividir los sistemas en niveles: las fachadas serían el punto de entrada a cada nivel
5) EstructuraClases del
subsistema
Clases del
subsistema
BB
AA
CC
DD
FachadaFachada
EE
Facade
6) Participantes
♦ Fachada: delegar las peticiones de los clientes en los objetos del subsistema
♦ Clases del subsistema: implementar la funcionalidad del subsistema
7) Colaboraciones
♦ Los clientes se comunican con el subsistema a través de la fachada, que reenvía las peticiones a los objetos del subsistema apropiados y puede realizar también algún trabajo de traducción
♦ Los clientes que usan la fachada no necesitan acceder directamente a los objetos del sistema
14
Facade
8. Ejemplo: Fachada para el acceso a BBDD vía JDBC
♦ Para consultar una base de datos es necesario colaborar con objetos de al menos cinco clases diferentes
1. Connection. Conexión a la BBDD
2. DatabaseMetadata. Acceso a nombres de tablas y campos
3. Statement. Crea la sentencia SQL
4. ResultSet. Recuperar la información en crudo
5. ResultSetMetaData. Accede a los campos del ResultSet
♦ Es más que evidente que se puede simplificar la colaboración
Facade
9) Consecuencias
♦ Oculta a los clientes de la complejidad del subsistema y lo hace más fácil de usar
♦ Favorece un acoplamiento débil entre el subsistema y sus clientes, consiguiendo que los cambios de las clases del sistema sean transparentes a los clientes
♦ Facilita la división en capas y reduce dependencias de compilación
♦ No se impide el acceso a las clases del sistema
15
Facade
10) Implementación
♦ Se puede reducir aún más el acoplamiento haciendo que la fachada sea una clase abstracta, de forma que se pueda escoger entre distintas implementaciones del subsistema
♦ Java y las últimas versiones de C++ facilitan la definición de clases privadas a un subsistema.
11) Patrones relacionados
♦ Las fachadas suelen ser Singletons
♦ Indirección (GRASP)
♦ Controlador (GRASP). Los controladores suelen actuar como puntos de entrada (fachadas) de la capa lógica
El Camino
♦ Qué es un Patrón de Diseño (PD)
� Qué no es un PD
16
El camino
� Bibliotecas
♦ Frameworks
♦ Idioms
♦ Antipatrones
♦ Refactorizaciones
Bibliotecas (Toolkits)
♦ También conocidas como librerías y Toolkits
♦ Conjunto de clases diseñado para ser reutilizados: TADs, manejo de periféricos, gráficos, gestión de documentos XML, … Pueden verse como el equivalente en OO de las bibliotecas de subrutinas
♦ Influencia baja/local en el diseño de la aplicación cliente
♦ Una cuestión clave de su diseño reside en conseguir facilidad de uso para el máximo número de escenarios sin complicar la interfaz ni reducir el rendimiento
♦ Bibliotecas vs PP.DD
♦ ¿Son comparables?♦ ¿Qué contienen?
♦ ¿Cuál es su tamaño medio?
17
El Camino
♦ Bibliotecas
� Frameworks
♦ Idioms
♦ Antipatrones
♦ Refactorizaciones
En el origen de los tiempos
♦ Un framework era un entorno de desarrollo (IDE)
♦ “Componentes” habituales:
♦ Editor de textos
♦ Ayuda integrada
♦ Compilador
♦ Biblioteca de controles visuales
♦ Biblioteca de controles datos
♦ Constituían un marco de trabajo para el desarrollo de aplicaciones
♦ Visual Basic popularizó el concepto en la industria
18
Qué es un framework hoy
♦ Conjunto de clases parcialmente funcional (no es una aplicación) para un dominio de aplicación
♦ Les falta aquello que es propio de la aplicación
♦ Ejemplos: AWT, Swing, Struts, Junit, Compact Framework, James (genuinamente andaluz), …
♦ Gran influencia en el diseño de la aplicación cliente
♦ Frameworks vs PP.DD
♦ ¿Son comparables?
♦ ¿Qué contienen?
♦ ¿Cuál es su tamaño medio?
El principio de Hollywood
19
El principio de Hollywood
Main() {
i1 = new I1();
i2 = new I2();
i1 = i2.m(i1.g());
}
Ventajas e inconvenientes
♦ Reutilización de diseño y código
♦ Experiencia del diseñador del framework
♦ Costes de producción reducidos
♦ Es difícil encontrar el framework apropiado
♦ Es difícil usar más de un framework al mismo tiempo
♦ Son difíciles de construir y de aprender a usar
20
El camino
♦ Bibliotecas
♦ Frameworks
� Idioms
♦ Antipatrones
♦ Refactorizaciones
Idioms
♦ Una forma característica de utilizar un LP [Fiadeiro]
♦ Patrón de bajo nivel específico de un LP. Describen soluciones a problemas de implementación de un determinado LP [Buschmann]
♦ gestión de memoria en C++
♦ Idiom K-R: while (*dest++=*src++)
♦ Para algunos, el Singleton no es un patrón de diseño
♦ Una colección de idioms conforman un estilo
♦ Las diferencias entre PP.DD e idioms son difusas
♦ Algunos PP.DD de hoy serán idioms mañana
♦ Iterator, singleton [Gamma]
♦ interface [Grand]
♦ Los PP.DD son casi independientes del L.P
21
El camino
♦ Bibliotecas
♦ Frameworks
♦ Idioms
� Antipatrones
♦ Refactorizaciones
Antipatrones
♦ Se aprende de los errores más que de los aciertos
♦ Recetas que no deben emplearse
♦ Intentan reutilizar conocimiento de modo similar a los PP.DD
♦ Ejemplos
♦ The blob
♦ Poltergeists
♦ Cut and paste
♦ Spaguetti code
♦ ….
♦ http://www.antipatterns.com/
22
El camino
♦ Bibliotecas
♦ Frameworks
♦ Idioms
♦ Antipatrones
� Refactorizaciones
Refactorizaciones
♦ M. Fowler las ha popularizado
♦ No siempre se consigue un diseño adecuado ¿qué hacer en tales situaciones?
♦ Nada. En ocasiones es lo más rentable
♦ Refactorizar en las sucesivas operaciones de mantenimiento
♦ La refactorización mantiene invariable la funcionalidad
♦ Están organizadas en catálogos
♦ Muchas de ellas están muy relacionadas con PP.DD
♦ Pull-up. Muy relacionada con el PD Template Method
23
Bibliografía
♦ Se recomienda revisar los siguientes enlaces:
♦ WIKIPEDIA (design patterns, antipatterns, framework, idioms)
♦ Historia de los patrones (http://c2.com/cgi-bin/wiki?HistoryOfPatterns)
♦ Refactorización (http://c2.com/cgi-bin/wiki?HistoryOfPatterns)
Cuestiones
♦ Resolver los test de exámenes de convocatorias anteriores
24
Cuestiones
!Gracias!
♦ ¿Podemos mejorar esta lección?
♦ Mándanos un email a [email protected]
♦ Visite la web de la asignatura www.lsi.us.es