Introducción a los Patrones de Diseño

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”


♦ 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


♦ Orígenes de los PP.DD

♦ Definiciones

♦ Clasificación

♦ Ejemplo: PD Singleton


� Orígenes de los PP.DD

♦ Definiciones

♦ Clasificación


4

Qué es un PDOrígenes de los PP.DD

♦ Christopher Alexander (Viena, 1936)

1977

1979


Kent BeckWardCunnighan

1. Window per Task

2. Few Panes

3. Standard Panes

4. Nouns and Verbs

5. Short Menus

OOPSLA 87

5


♦ 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:


♦ 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


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


� Definiciones

♦ Clasificación


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


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)


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?)


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


♦ Definiciones

� Clasificación


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


♦ 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


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


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


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

Documents

Introducción a los Patrones de Diseño