6 3-templates y patrones

Diseño de SoftwareDr. Amos Sorgen

Agosto de 2011 slide 1

Templates

Autor Dr Amos Sorgen // Editor Mg Ing Rolando TitioskyBasado en: Ing de Software (Ian Sommersville); UML y Patrones (Craig Larman)

Diseño de software Dr. Amos Sorgen

2Agosto 2011

Function Templates• Nos permite escribir funciones genéricas que pueden ser

usadas con varios tipos de datos.• Sin templates, se tendrían que rescribir muchas funciones

(y clases). • Ejemplo: una función que retorna el máximo de dos

valores. int max(int x, int y) { return (x < y) ? y : x; } float max(float x, float y) { return (x < y) ? y : x; }

template <typename T> T max(T x, T y) { return (x < y) ? y : x; }Esta funcion funciona con cualquier tipo que se pueda

comparar con el “operador <“ Funciona hasta con una clase desconocida por el

compilador, si se implementa el “operador <“

Diseño de SoftwareDr. Amos Sorgen

Agosto de 2010 slide 3

Patrones de Diseño OO


4Agosto 2011

Patrones de diseño• Los patrones de diseño son la base

para solucionar problemas de diseño comunes a distintas aplicaciones.

• Proveen una solución estándar para un problema común de diseño

• Se presentan en formas distintas porque lo que varia es el dominio del problema y por lo tanto las clases que entran en juego


5Agosto 2011

Ejemplo de problemas similares• Modelar en un sistema S que tiene Y-s y z-s. A su vez los Y-s

pueden recursivamente incluir Y-s y z-s (las z-s no pueden incluir a nadie) formando un arbol cuyas ramas son las Y-s y cuyas hojas son las z-s.

• Hay muchas actividades comunes a las Y-s y a las z-s que cuando se aplican a las Y-s se aplican recursivamente:– Delete()– Copy()– Display()– Move()– …

• Hay actividades que solo aplican a las Y-s– Add(Y or z)– GetNextChild(Y or z)

• Ejemplos: – S = sistema operativo Y = directorio z= archivos– S = sistema grafico Y = gráficos complejos z = elementos

geométricos– S = un sistema de ventanas Y = ventanas z = controles


6Agosto 2011

Se Necesita…• Componer objetos en estructuras de

árbol para representar jerarquías parte-todo

• Y Que permita tratar a las “hojas” y a las “ramas” de manera uniforme (composición recursiva).


7Agosto 2011

Solucion particular


8Agosto 2011

Solución general: Composite Patern


9Agosto 2011

Descripción de los patrones • Nombre del patrón: nombre estándar del patrón por el cual

será reconocido en la comunidad (normalmente se expresan en inglés).

• Clasificación del patrón: creacional, estructural o de comportamiento.

• Intención: ¿Qué problema pretende resolver el patrón? • Motivación: Escenario de ejemplo para la aplicación del patrón. • Aplicabilidad: Usos comunes y criterios de aplicabilidad del

patrón. • Estructura: Diagramas de clases oportunos para describir las

clases que intervienen en el patrón. • Consecuencias: Consecuencias positivas y negativas en el

diseño derivadas de la aplicación del patrón. • Implementación: Técnicas o comentarios oportunos de cara a

la implementación del patrón. • Código de ejemplo: Código fuente ejemplo de implementación

del patrón. • Usos conocidos: Ejemplos de sistemas reales que usan el

patrón.


10Agosto 2011

Gang of Four La 'Banda de los cuatro',

• Es el nombre con el que se conoce comúnmente a los autores del libro Design Patterns. – Erich Gamma, Richard Helm, Ralph Johson, John Vlissides

• Pero se usa también como nombre genérico para los 23 patrones que aparecen en ese libro

Patrones creacionales: Se aplican cuando hay creación de objetos

Patrones estructurales: Se aplican cuando hay composición de objetos

Patrones conductuales: Se aplican cuando objetos interactúan


11Agosto 2011

GoF - Patrones Creacionales

• Absract Factory - Fábrica AbsractaCrea la instancia de la clase “hija” que corresponde al contexto (ej. BotónWindows o un BotónLinux )

• Factory Method – Metodo de fabricaDelega toda la creación de la instancia a la subclase.

• Builder - ConstructorConstruye objetos complicados usando métodos en las subclases

• Prototype - PrototipoCrea una nueva instancia, copiando un prototipo

• SingletonUna clase de las que sólo una sola instancia puede existir


12Agosto 2011

GoF - Estructurales• Adapter - Adaptador

Adapta interfaces de diferentes clases para ser usadas por una unica.

• Bridge - PuenteCrea un puente entre la verdadera clase y la clase como es usada por otras clases

• Composite - CompuestoUna estructura de árbol de objetos simples y compuestos

• Decorator - DecoradorAñade funcionalidades a los objetos de forma dinámica (run time)

• Facade - FachadaUna clase única que provee una interfase simplificada a todo un subsistema

• Flyweight - Peso moscaPermite compartir memoria entre objetos similares.

• Proxy - ApoderadoUn objeto que representa otro objeto pero que consume muchos menos recursos


13Agosto 2011

GoF - de comportamiento - 1• Chain of Responsibilities - Cadena de

ResponsabilidadesUna manera de pasar un pedido, en una cadena de objetos hasta que se encuentre aquel que pueda cumplirlo.

• Command - ComandoEncapsula la petición de un comando en un objeto que puede ser guardado, trasmitido, etc.

• Interpreter - IntérpreteInterpreta frases de un lenguage.

• Iterator - ItereadorAccede secuencialmente a los elementos de una colección

• Mediator - MediadorSimplifica la comunicación entre las clases

• Memento - RecuerdoCaptura y restaura si es necesario el estado de un objeto


14Agosto 2011

GoF - comportamiento – 2• Observer - Observador

Una forma de notificar un cambio en un objeto a otros objetos • State - Estado

Altera el comportamiento de un objeto cuando su estado cambia

• Strategy - EstrategiaEncapsula un algoritmo dentro de un objeto. De esta forma se puede seleccionar que algoritmo correr en tiempo de ejecucion.

• Template Method - Plantilla MétodoAplaza la implementación concreta de un algoritmo a una subclase

• Visitor - VisitanteSe usa para introducir definir nuevas funcionalidades a una clase sin necesidad de cambiarla.


15Agosto 2011

Otra categorización de los Patrones de diseño – 1

• Patrones de descomposición estructural• Se aplican cuando se diseñan subsistemas y componentes complejos usando

módulos que cooperan unos con otros• Ejemplo whole-part

• Patrones de organización de trabajo • Se aplican cuando componentes colaboran juntos para resolver un problema complejo• Ejemplo: master-slave

• Patrones de acceso de control• Se aplican cuando hay que “cuidar” y “controlar” el acceso a servicios y componentes• Ejemplo: proxy

• Patrones de administración• Se aplican cuando hay que manejar colecciones homogéneas de objetos, servicios y

componentes en su totalidad.• Ejemplo: command processor, view handler

• Patrones de comunicación• Se aplican cuando hay que organizar comunicación entre componentes• Ejemplo: forward-receiver, dispatcher-server, publisher-subscriber


16Agosto 2011

Patrones populares• Composite• Singleton• Factory• Abstract factory (Factory method)• Adapter• Façade• Observer• Strategy• State• Decorator• Prototype• Proxy• Chain of responsibility• Command• Iterator• Mediator


17Agosto 2011

SingletonProblema: Se quiere

asegurar que una clase tiene una sola instancia

Ejemplo: Un sistema que administra los recursos humanos de una empresa necesite que no haya mas que un unico objeto “presidente”

Generalización: “Pool Object”

Class A { Private static A* The_a; … Otros datos privados … Otros metodos privados Public A() { If (~The_a) The_a = make_a(); return A& The_a; } … otros datos publicos … otros metodos publicos}

A* A::The_a = NULL;


18Agosto 2011

FactoryProblema: Se quiere tratar homogéneamente la

creación y subsecuente manipulación de objetos que responden a un mismo concepto pero que tienen distinto comportamiento en distintas circunstancias

Ejemplo: Manipulación de elementos de IU bajo distintos sistemas operativos.

Solución: Se genera una herencia de “factories” paralela a la herencia de los objetos.Para ello se crea el objeto (en el ejemple de “WidgetFactory”) de acuerdo a la clase especifica que dictan las circunstancias


Factory


20Agosto 2011

Abstract Factory

http://es.wikipedia.org/wiki/Archivo:Factory_Method.png


21Agosto 2011

AdapterProblema: Proporcionar una interfazestable para clases que dan losmismos servicios pero con distintas

interfacesEjemplo: Agregar en una librería grafica

un elemento que pertenece a otraSolución: Estandarizar las interfacesoriginales, mediante un objeto adaptadorintermedio


22Agosto 2011

Adapter - Ejemplo

http://es.wikipedia.org/wiki/Archivo:ClassAdapter.png


23Agosto 2011

FacadeProblema: Se tiene

una biblioteca de clases que dan muchos servicios con muchos métodos y se quiere suministrar una interfaz unificada y sencilla para los usuarios de la biblioteca

Ejemplo:


24Agosto 2011

Facade Ejemplo


25Agosto 2011

Facade - Solución

http://upload.wikimedia.org/wikipedia/commons/d/d4/Facade_UML_class_diagram.svg


26Agosto 2011

Observer

Problema: Se quiere que, cuando el objeto A cambie su estado, los objetos X, Y, Z sean notificados y se actualicen de acuerdo.

Solución: A tiene una lista de objetos “observadores” que están interesados en sus cambios. Hay un mecanismo de “registrarse como observador”


27Agosto 2011

Observer - Ejemplo


28Agosto 2011

StrategyProblema: Aplicar distintas estrategias de acuerdo a la situación en

tiempo de ejecución.Ejemplo: La forma de validar los datos entrantes es función del tipo

de datos, la fuente de los datos, u otros factores de discriminación.

Solución: Definir cada estrategia como una clase independiente. De acuerdo al contexto se crea la clase concreta que corresponde y en su creación se aplica la estrategia pertinente.


29Agosto 2011

StateProblema: Se quiere encapsular (abstraer) las

operaciones que dependan del estado de un objeto.

Ejemplo: Para una clase “carita” , los estados serían - Triste

- Serio - ContentoY la operación que depende del estado sería -

“dibujar”


30Agosto 2011

State – Cambios de estado

enfadarse

alegrarse

alegrarse

Cambios de ánimo

Cara EstadoCara

v: EstadoCara

alegrarenfadarpintar…


Triste


Contenta


Seria


Cara:alegrar{v.alegrar}


31Agosto 2011

DecoratorProblema: Se quiere añadir funcionalidad (distinta) a toda una serie

de clases heredadasEjemplo: Tenemos una super-clase Ventana y queremos añadirle

funcionalidad para que se dibuje un alrededor de todos los tipos de ventanas.

Solución: Se crea una clase “XX_decorado” que hereda de la super-clase y al mismo tiempo la contiene. De forma que accesando a una funcion de “XX_decorado”, se accesa a la misma función de XX y a los agregados


32Agosto 2011

Prototype• Problema: Sin saber que sub-clase de objeto se esta

manipuleando, se quiere tener una copia del mismo. • Ejemplo: En un sistema gráfico se quiere copiar la figura

elegida por el usuario en la IU.• Solución: Se crea una jerarquía que produce objetos

“cloneando” prototipos de acuerdo al tipo de objeto que se quiera clonear.


33Agosto 2011

Proxy • Problema: Se quiere acceder a un objeto pero sin crearlo localmente

porque su creación local consume muchos recursos.• Ejemplo: Se quiere acceder sólo al nombre del cliente, que reside en el

objeto tipo “cliente” en un server remoto. Seria muy costoso recrear todo el objeto.

• Solución: Se crea una jerarquía que permita crear un objeto “liviano” conectado al objeto “pesado”

• Generalización: “Proxy – New Function”


34Agosto 2011

Chain of Responsibility • Problema: Se quiere que las peticiones emitidas al sistema sean

atendidas por distintos objetos receptores en función del estado del sistema (dinámicamente).

• Ejemplo: No se sabe qué impresoras está libre y se quiere que el pedido de impresión llegue la que esta libre y lo realice.

• Solución: establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la petición en función de un criterio establecido.


35Agosto 2011

Command • Problema: Se quiere tratar a una función/

pedido/ comando como si fuera un objeto para poder – registrarlos, – gestionar colas, – restaurar el estado del sistema (si es necesario) – tratarlos con una interfaz generalizada.

• Ejemplo: Queremos notificar distintos sucesos en el sistema en un orden que no sea la orden en que acontecieron.

• Solución: Los objetos en vez de invocar a otros, crean objetos de tipo “commando” que son ejecutados asincrónicamente a su producción.


36Agosto 2011

Command • A a, Queue q ;• ….• /* a.do1;• /* A_command hereda de Command• A_command c = do_command(a, “do1) ;• Q.add(c) ;• -----------------• Queue::serve_next {• …. • Command c = next();• c.execute();• }


37Agosto 2011

Command - Solución


38Agosto 2011

Iterator • Problema: Se quiere tratar a toda colección

de objetos en forma estándar irrespectivamente de la estructura de la colección

• Ejemplo: Queremos siempre tener la misma forma de tratar una colección:– Primero(), – Siguiente(), – HayMas() – ElementoActual()

• Solucion: Crear para toda clase de tipo contenedor, el “Iterator” que se ocupa de implementar las funciones estándar


39Agosto 2011

Iterator - SoluciónVector vec = new Vector();

vec.add( new String( "hola“ ) );

vec.add( new String( "adios“ ) );

Iterator it = vec.iterator();

while ( it.hasNext() ) System.out.println( (String) it.next() );


40Agosto 2011

Mediator • Problema: Se quiere encapsular las interacciones de todo un conjunto de

objetos (colegas) en un solo objeto para evitar tener conexiones de tipo N:N (bajo acoplamiento).

• Los objetos ya no se comunican directamente entre sí, sino a través del mediador. Esto reduce las dependencias entre los objetos que se comunican .

• Ejemplo: Una ventana con numerosos componentes gráficos (widgets) que tienen fuertes dependencias entre si. reglas del tipo "si el campo de edición E2 está lleno, entonces se inhabilita habilita el botón B1 y el campo de edición E3”.Se quiere desacoplar los widgets

• Solución: Crear un objeto mediador que todos los “colegas” conocen. Las interacciones entre colegas se realizan a través del envío de mensajes al mediador y de este a los colegas.


41Agosto 2011

Mediator - Solución


42Agosto 2011

Preguntas

6 3-templates y patrones

Documents

Transcript of 6 3-templates y patrones