Conf01 - Introducci+ N PDF

Universidad de las Ciencias Informáticas
Facultad 4
Curso Optativo Diseño de patrones

Introducción
MSc. Angel Alberto Vazquez Sánchez

Bibliografía
●
Ezust, A., & Ezust, P. (2007). An introduction to design
patterns in C++ with Qt 4. Prentice-Hall.
●
Gamma, E. (1995). Design patterns: elements of reusable
object-oriented software. Pearson Education India.
●
Metsker, S. J., & Wake, W. C. (2006). Design patterns in
Java. Addison-Wesley Professional
●
Grand, M. (2002). Patterns in Java Vol. 1. John Wiley &
Sons.
2
Objetivo
●
Caracterizar los patrones de diseño de software
para la contrucción de sistemas informáticos
reutilizables.
3
Sumario
●
¿Qué es un patrón de diseño?
●
Describiendo patrones de diseño
●
El catálogo de patrones de diseño
●
¿Cómo los patrones de diseño resuelven resuelven
problemas de diseño?
●
¿Cómo seleccionar un patrón de diseño?
●
¿Cómo usar un patrón de diseño?
4
Introducción
5
Cuando la POO va mal
●
Java Input Validation
●
En el pasado, Java Swing
solamente brindaba para la
entrada de texto el componente
JtextField.
●
JnumericTextField apareció
rapidamente en la comunidad.
6
7
Fallo en la POO
• Muchas clases
• Difícil de mantener
• Desarrolladores frustados
8
9
Entrada de los patrones de diseño
●
Soluciones reusables y probadas
●
Sostenibles para largas ejecuciones
10
•
Introducido por Cristopher
Alexander en 1977
•
Y fue un arquitecto
11
Cada patrón describe un problema

que ocurre una y otra vez en nuestro
entorno, y luego describe el núcleo
de la solución a ese problema, de tal
manera que se puede utilizar esta
solución un millón de veces, sin tener
que hacerlo nunca dos veces de la
misma manera 12
Que no son los patrones
●
No son una solución detallada
●
No es una guía para ayudarte a construirlo
13
Los patrones son:
●
Descripciones de soluciones existentes y
funcionales
●
Tu trabajo: Aplicarlo a tu mundo
14
Descripción de patrones
●
Un nombre que se usa comúnmente para el patrón.
Se dan nombres alternativos en los casos en que el
patrón se conoce por más de un nombre.
●
Una descripción del problema que incluye un
ejemplo concreto y una solución específica para el
problema concreto.
●
Un resumen de las consideraciones que conducen a
la formulación de una solución general o a evitar la
solución.
15
Descripción de patrones
●
Una solución general.
●
Las consecuencias -buenas y malas- de usar la
solución dada para resolver un problema.
●
Una lista de patrones relacionados.
16
17
Patrones en el software
●
Definidos por GoF
●
Categorizados en:
– Creacionales
– Estructurales
– Comportamiento
18
Gang of Four
Erich Gamma Richard Helm Ralph Johnson John Vlissides
19
Catálogo de patrones de diseño
●
Abstract Factory (Fábrica de Abstractos)
●
Adapter (Adaptador)
●
Bridge (Puente)
●
Builder (Constructor)
●
Chain of Responsibility (Cadena de Responsabilidad)
●
Command (Comando)
●
Composite (Compuesto)
20
●
Decorator (Decorador)
●
Facade (Fachada)
●
Factory Method (Método Fábrica)
●
Flyweight (Peso mosca)
●
Interpreter (Intérprete)
●
Iterator (Iterador)
●
Mediator (Mediador)
21
●
Memento (Memento)
●
Observer (Observador)
●
Prototype (Prototipo)
●
Proxy (Apoderado)
●
Singleton
●
State (Estado)
●
Strategy (Estrategia)
22
●
Template Method (Método Plantilla)
●
Visitor (Visitante)
23
Organizando el catálogo
Propósito
Creacional Estructural De Comportamiento
Adapter Interpreter
Clase Factory Method
campo de aplicación
(class) Template Method

Chain of Responsability
Adapter
Command
(object)
Iterator
Abstract Factory Bridge
Mediator
Builder Composite
Objeto Memento
Prototype Decorator
Observer
Singleton Facade
State
Flyweigth
Strategy
Proxy
Visitor 24
Estudio independiente
Buscar en el libro Design Pattern – Elements of
reusable object oriented software (epígrafe 1.5)
las relaciones existentes entre los diferentes
patrones de diseño.
Entragar un mapa conceptual donde se describan
estas relaciones.
25
Cómo los patrones de diseño resuelven los
problemas de diseño
Los patrones de diseño resuelven muchos de los
problemas cotidianos a los que se enfrentan los
diseñadores orientados a objetos, y de muchas maneras
diferentes.
26
Encontrando Objetos Apropiados
Los programas orientados a objetos se componen de
objetos.
Un objeto empaqueta tanto los datos como los
procedimientos que operan con ellos.
Los procedimientos son típicamente llamados métodos u
operaciones.
Un objeto realiza una operación cuando recibe una
petición (o mensaje) de un cliente.
27
Las peticiones son la única forma de obtener un objeto
para ejecutar una operación. Las operaciones son la única
manera de modificar los datos internos de un objeto.
Debido a estas restricciones, se dice que el estado interno
del objeto está encapsulado; no se puede acceder a él
directamente, y su representación es invisible desde fuera
del objeto.
28
La parte difícil del diseño orientado a objetos es
descomponer un sistema en objetos.
La tarea es difícil porque entran en juego muchos
factores: encapsulación, granularidad, dependencia,
flexibilidad, rendimiento, evolución, reutilización, y así
sucesivamente.
Todos ellos influyen en la descomposición, a menudo de
manera conflictiva.
29
Muchos objetos en un diseño provienen del modelo de
análisis.
Pero los diseños orientados a objetos a menudo terminan
con clases que no tienen equivalente en el mundo real.
●
Algunas de estas clases son de bajo nivel, como los
arrays.
●
Otros son de un nivel mucho más alto.
30
Por ejemplo, el patrón Composite introduce una
abstracción para tratar objetos uniformemente que no
tiene una contraparte física.
El modelado estricto del mundo real conduce a un sistema
que refleja las realidades de hoy, pero no necesariamente
las del mañana. Las abstracciones que surgen durante el
diseño son la clave para flexibilizar el diseño.
31
Los patrones de diseño le ayudan a identificar las
abstracciones menos obvias y los objetos que pueden
capturarlas.
Por ejemplo, los objetos que representan un proceso o un
algoritmo no ocurren en la naturaleza, pero son una parte
crucial de los diseños flexibles.
El patrón Strategy describe cómo implementar familias de
algoritmos intercambiables.
32
El patrón del Estado representa cada estado de una
entidad como un objeto.
Estos objetos rara vez se encuentran durante el análisis
o incluso en las primeras etapas del diseño; se
descubren más tarde en el curso de hacer un diseño
más flexible y reutilizable.
33
Determinando la granularidad del objeto
Los objetos pueden variar enormemente en tamaño y
número. Pueden representar todo, desde el hardware
hasta aplicaciones completas.
¿Cómo decidimos qué debe ser un objeto?
34
Los patrones de diseño también abordan este problema.
El patrón Facade describe cómo representar una imagen
completa subsistemas como objetos, y el patrón
Flyweight describe cómo soportar grandes cantidades de
objetos en las más finas granularidades.
35
Otros patrones de diseño describen formas específicas
de descomponer un objeto en objetos más pequeños.
●
Abstract Factory y Builder producen objetos cuyas
únicas responsabilidades son creando otros objetos.
●
Visitante y Comando ceden objetos cuyas únicas
responsabilidades son implementar una solicitud en
otro objeto o grupo de objetos.
36
Especificación de interfaces de objetos
Cada operación declarada por un objeto especifica el nombre
de la operación, los objetos que toma como parámetros y el
valor de retorno de la operación. Esto se conoce como la firma
de la operación.
El conjunto de todas las firmas definidas por las operaciones
de un objeto se llama la interface con el objeto.
La interfaz de un objeto caracteriza el conjunto completo de
peticiones que se pueden enviar al objeto. Cualquier petición
que coincida con una firma en la interfaz del objeto puede ser
enviada al objeto.
37
Un tipo es un nombre usado para denotar una interfaz
en particular. Se considera que un objeto tiene el tipo
"Window" si acepta todas las peticiones de las
operaciones definidas en la interfaz denominada
"Window".
Un objeto puede tener muchos tipos, y objetos muy
diferentes pueden compartir un tipo. Parte de la
interfaz de un objeto puede ser caracterizada por un
tipo, y otras partes por otros tipos. 38
Dos objetos del mismo tipo sólo necesitan
compartir partes de sus interfaces. Las interfaces
pueden contener otras interfaces como
subconjuntos.
Decimos que un tipo es un subtipo de otro si su
interfaz contiene la interfaz de su supertipo.
A menudo hablamos de un subtipo que hereda la
interfaz de su supertipo. 39
Las interfaces son fundamentales en los sistemas orientados a
objetos. Los objetos sólo se conocen a través de sus interfaces.
No hay manera de saber nada sobre un objeto o de pedirle que
haga algo sin pasar por su interfaz.
La interfaz de un objeto no dice nada acerca de su
implementación; los diferentes objetos son libres de
implementar las solicitudes de forma diferente.
Esto significa que dos objetos con implementaciones
completamente diferentes pueden tener interfaces idénticas.
40
Cuando se envía una solicitud a un objeto, la operación
concreta que se realiza depende tanto de la solicitud
como del objeto receptor.
Diferentes objetos que soportan peticiones idénticas
pueden tener implementaciones diferentes de las
operaciones que satisfacen estas peticiones.
La asociación en tiempo de ejecución de una solicitud a
un objeto y a una de sus operaciones se conoce como
enlazamiento dinámica (dynamic binding). 41
La enlazamiento dinámico significa que la emisión de una
solicitud no le compromete a una implementación en
particular hasta el momento de la ejecución.
En consecuencia, puede escribir programas que esperan un
objeto con una interfaz particular, sabiendo que cualquier
objeto que tenga la interfaz correcta aceptará la solicitud.
Además, la enlazado dinámico permite sustituir objetos que
tienen interfaces idénticas entre sí en tiempo de ejecución.
42
Esta sustituibilidad se conoce como polimorfismo, y es
un concepto clave en los sistemas orientados a objetos.
Permite que un objeto cliente haga algunas
suposiciones sobre otros objetos más allá de soportar
una interfaz en particular.
El polimorfismo simplifica las definiciones de los
clientes, separa los objetos entre sí y les permite variar
sus relaciones entre sí en tiempo de ejecución.
43
Los patrones de diseño le ayudan a definir las
interfaces identificando sus elementos clave y los
tipos de datos que se envían a través de una
interfaz.
Un patrón de diseño también podría decirle lo que
no debe poner en la interfaz.
44
El patrón Memento es un buen ejemplo.
Describe cómo encapsular y guardar el estado interno de un
objeto para que el objeto pueda ser restaurado a ese estado más
tarde.
El patrón estipula que los objetos Memento deben definir dos
interfaces:
●
una restringida que permite a los clientes guardar y copiar
recuerdos, y
●
una privilegiada que sólo el objeto original puede utilizar para
almacenar y recuperar el estado del recuerdo. 45
Los patrones de diseño también especifican las relaciones entre
las interfaces.
En particular, a menudo requieren que algunas clases tengan
interfaces similares, o imponen restricciones a las interfaces de
algunas clases.
●
Por ejemplo, tanto Decorator como Proxy requieren que las
interfaces de los objetos Decorator y Proxy sean idénticas a
las de los objetos decorados y proxy.
●
En Visitor, la interfaz Visitor debe reflejar todas las clases de
objetos que los visitantes pueden visitar. 46
Clase versus Tipo
Es importante entender la diferencia entre la clase de un objeto
y su tipo.
●
La clase de un objeto define cómo se implementa el objeto.
●
La clase define el estado interno del objeto y la ejecución de
sus operaciones.
●
Por el contrario, el tipo de un objeto sólo se refiere a su
interfaz: el conjunto de peticiones a las que puede responder.
●
Un objeto puede tener muchos tipos y objetos de diferentes
clases pueden tener el mismo tipo.
47
Clase versus Tipo
Por supuesto, hay una estrecha relación entre
clase y tipo.
Dado que una clase define las operaciones que
un objeto puede realizar, también define el tipo de
objeto.
Cuando decimos que un objeto es una instancia
de una clase, implicamos que el objeto soporta la
interfaz definida por la clase. 48
Herencia de Clase versus Herencia de
Interfaz
También es importante entender la diferencia entre herencia
de clase y herencia de interfaz (o subtipo).
La herencia de clase define la implementación de un objeto
en términos de la implementación de otro objeto. En resumen,
es un mecanismo para compartir código y representación.
Por el contrario, la herencia (o subtipado) de la interfaz
describe cuándo se puede utilizar un objeto en lugar de otro.
Es fácil confundir estos dos conceptos, porque muchos
idiomas no hacen explícita la distinción.
49
Herencia de Clase versus Herencia
de Interfaz
Muchos de los patrones de diseño dependen de esta
distinción.
Por ejemplo, los objetos en una cadena de responsabilidad
deben tener un tipo común, pero normalmente no comparten
una implementación común.
En el patrón Composite, Component define una interfaz
común, pero Composite a menudo define una implementación
común.
Comando, Observador, Estado y Estrategia a menudo se
implementan con clases abstractas que son puras interfaces. 50
de Interfaz
●
La herencia de clases es básicamente sólo un mecanismo
para extender la funcionalidad de una aplicación mediante
la reutilización de la funcionalidad en clases parentales.
●
Permite definir rápidamente un nuevo tipo de objeto en
términos de uno antiguo.
●
Le permite obtener nuevas implementaciones casi de
forma gratuita, heredando la mayor parte de lo que
necesita de las clases existentes.
51
de Interfaz
●
Sin embargo, la reutilización de la implementación
es sólo la mitad de la historia.
●
También es importante la capacidad de la herencia
para definir familias de objetos con interfaces
idénticas (normalmente heredando de una clase
abstracta).
●
¿Por qué? Porque el polimorfismo depende de ello.
52
de Interfaz
●
Cuando la herencia se usa con cuidado (algunos dirán
correctamente), todas las clases derivadas de una clase
abstracta compartirán su interfaz.
●
Esto implica que una subclase simplemente añade o anula
operaciones y no oculta operaciones de la clase principal.
●
Todas las subclases pueden entonces responder a las
peticiones en la interfaz de esta clase abstracta,
convirtiéndolas en todos los subtipos de la clase abstracta.
53
de Interfaz
Hay dos beneficios de manipular objetos únicamente en
términos de la interfaz definida por clases abstractas:
●
Los clientes no son conscientes de los tipos específicos de
objetos que utilizan, siempre y cuando los objetos se
adhieran a la interfaz que los clientes esperan.
●
Los clientes no son conscientes de las clases que
implementan estos objetos. Los clientes sólo conocen las
clases abstractas que definen la interfaz.
54
de Interfaz
Esto reduce tanto las dependencias de implementación
entre subsistemas que conduce al siguiente principio de
diseño reutilizable orientado a objetos:
Programar a una interfaz, no a una implementación.
55
de Interfaz
●
No declarar que las variables son instancias de clases
concretas particulares.
●
En su lugar, comprométase sólo con una interfaz
definida por una clase abstracta.
Encontrará que este es un tema común de los patrones
de diseño
56
Poner en uso los mecanismos de
reutilización
La mayoría de la gente puede entender
conceptos como objetos, interfaces, clases y
herencia.
El reto es al aplicarlos para construir software
flexible y reutilizable, y los patrones de diseño
pueden mostrarte cómo.
57
Herencia versus Composición
Las dos técnicas más comunes para reutilizar la
funcionalidad en sistemas orientados a objetos
son
●
la herencia de clases y
●
la composición de objetos.
58
La herencia de clases permite definir la
implementación de una clase en términos de la de
otra.
La reutilización por subclase se denomina a menudo
reutilización de caja blanca.
El término "caja blanca" se refiere a la visibilidad: Con
la herencia, los aspectos internos de las clases padre
son a menudo visibles para las subclases.
59
La composición de objetos es una alternativa a la
herencia de clase. La nueva funcionalidad se obtiene
mediante el ensamblaje o composición de objetos para
obtener una funcionalidad más compleja.
La composición de objetos requiere que los objetos que
se están componiendo tengan interfaces bien definidas.
Este estilo de reutilización se llama reutilización de caja
negra, porque no se ven los detalles internos de los
objetos.
60
Favorecer la composición de objetos sobre la
herencia de clases le ayuda a mantener cada
clase encapsulada y enfocada en una tarea.
Tus clases y jerarquías de clases seguirán siendo
pequeñas y es menos probable que se conviertan
en monstruos inmanejables.
61
Favorecer la composición de objetos sobre la

herencia de clase
62
Delegación
La delegación es una forma de hacer que la
composición sea tan poderosa para su
reutilización como la herencia.
En la delegación, dos objetos participan en la

ejecución de una solicitud: un objeto receptor
delega las operaciones a su delegado.
63
Delegación
64
Delegación
La principal ventaja de la delegación es que
facilita la composición de los comportamientos en
tiempo de ejecución y el cambio de la forma en
que se componen.
La delegación tiene una desventaja: El software
dinámico y altamente parametrizado es más difícil
de entender que el software más estático.
65
La única constante en el desarrollo de software
es:
68
Diseñar para el cambio
La única constante en el desarrollo de software
es:
69
La clave para maximizar la reutilización reside en
anticiparse a los nuevos requisitos y a los cambios en
los requisitos existentes, y en diseñar sus sistemas de
manera que puedan evolucionar en consecuencia.
Para diseñar el sistema de manera que sea robusto a
tales cambios, debe considerar cómo el sistema
podría necesitar cambiar a lo largo de su vida útil.
70
Un diseño que no tiene en cuenta los cambios
corre el riesgo de ser rediseñado en el futuro.
Estos cambios podrían implicar la redefinición y
reimplementación de la clase, la modificación del
cliente y la repetición de las pruebas.
71
Causas comunes de rediseño
A continuación se presentan algunas causas
comunes de rediseño junto con los patrones de
diseño que las abordan:
●
Creación de un objeto especificando una clase
explícitamente. Abstract Factory, Factory
Method, Prototype.
72
●
Dependencia de operaciones específicas.
Chain of Responsibility, Command.
●
Dependencia de la plataforma de hardware y
software. Abstract Factory, Bridge.
●
Dependencia de representaciones o
implementaciones de objetos. Abstract Factory,
Bridge, Memento, Proxy
73
●
Dependencias algorítmicas. Builder, Iterator,
Strategy, Template Method, Visitor.
●
Fuerte acoplamiento. Abstract Factory, Bridge,
Chain of Responsibility, Command, Facade,
Mediator, Observer
●
Ampliación de la funcionalidad mediante subclases.
Bridge, Chain of Responsibility, Composite,
Decorator, Observer, Strategy.
74
●
Incapacidad de alterar convenientemente las
clases. Adapter, Decorator, Visitor.
75
¿Cómo seleccionar un patrón de diseño?
●
Considere cómo los patrones de diseño resuelven los
problemas de diseño.
●
Escanear la sección Intención (Intent)
●
Estudiando como los patrones se interrelacionan.
●
Estudiar patrones de propósito similar
●
Examinar una causa de rediseño
●
Considere lo que debe ser variable en su diseño
76
1.Lea el patrón de una vez para obtener una visión
general
2.Vuelve y estudia las secciones Estructura,
Participantes y Colaboraciones.
3.Vea la sección Código de ejemplo para ver un
ejemplo concreto del patrón en código
4.Elegir nombres para los participantes del modelo que
sean significativos en el contexto de la aplicación
77
5.Definir las clases
6.Definir nombres específicos de aplicación para
operaciones en el modelo
7.Implementar las operaciones para llevar a cabo
las responsabilidades y colaboraciones en el
modelo.
78
Usando los patrones
●
Entenderlos
●
Memorizarlos
●
Aplicarlos repetidamente
79
Conclusiones
●
¿Qué es un patrón de diseño?
●
¿Qué problemas resuelven los patrones de
diseño?
●
¿Cómo podemos clasificar a los patrones?
●
¿Cuáles patrones se encuentran en cada
grupo?
80
81
Universidad de las Ciencias Informáticas
Facultad 4
Curso Optativo Diseño de patrones

Introducción
MSc. Angel Alberto Vazquez Sánchez

Conf01 - Introducci+ N PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Conf01 - Introducci+ N PDF

Cargado por

Copyright:

Formatos disponibles

Universidad de las Ciencias Informáticas

Curso Optativo Diseño de patrones

MSc. Angel Alberto Vazquez Sánchez

Cada patrón describe un problema

Erich Gamma Richard Helm Ralph Johnson John Vlissides

(class) Template Method

Favorecer la composición de objetos sobre la

En la delegación, dos objetos participan en la

Curso Optativo Diseño de patrones

MSc. Angel Alberto Vazquez Sánchez

También podría gustarte