Patrones de Diseño de Software

USB

Ingeniera de Software I

PATRONES DE DISEO DE SOFTWARE STRATEGY El patrn Estrategia (Strategy) es un patrn de diseo para el desarrollo de software. Se clasifica como patrn de comportamiento porque determina como se debe realizar el intercambio de mensajes entre diferentes objetos para resolver una tarea. El patrn estrategia permite mantener un conjunto de algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene e intercambiarlo dinmicamente segn sus necesidades. El libro Desing Patterns (Patrones de Diseo) describe el patrn Strategy con las siguientes palabras: Define una familia de algoritmos, encapsula cada una y las vuelve intercambiables. El patrn de Diseo Estrategia permite que el algoritmo vare independientemente de los clientes que lo utilizan Objetivo Definir un grupo de clases que representan un conjunto de posibles comportamientos. Estos comportamientos pueden ser fcilmente intercambiados en una aplicacin, modificando la funcionalidad en cualquier instante. Aplicabilidad Cualquier programa que ofrezca un servicio o funcin determinada, que pueda ser realizada de varias maneras, es candidato a utilizar el patrn estrategia. Puede haber cualquier nmero de estrategias y cualquiera de ellas podr ser intercambiada por otra en cualquier momento, incluso en tiempo de ejecucin. Si muchas clases relacionadas se diferencian nicamente por su comportamiento, se crea una superclase que almacene el comportamiento comn y que har de interfaz hacia las clases concretas. Si un algoritmo utiliza informacin que no deberan conocer los clientes, la utilizacin del patrn estrategia evita la exposicin de dichas estructuras. Aplicando el patrn a una clase que defina mltiples comportamientos mediante instrucciones condicionales, se evita emplear estas instrucciones, moviendo el cdigo a clases independientes donde se almacenar cada estrategia. Efectivamente lo que se comenta anteriormente, este patrn de diseo nos sirve para intercambian un sin nmero de estrategias posibles. Ventajas En primer lugar, es mucho ms fcil comprender cada uno de los distintos comportamientos si su implementacin est encapsulada en distintas clases, y no entrelazada en un nico mtodo. Esto permite de forma simple aadir nuevos comportamientos, y eliminar o modificar los existentes. En los casos en que existan varios objetos cuyo comportamiento sea prcticamente el mismo, esto se puede reducir a una nica clase que haga uso de distintas estrategias. Esto reduce el uso de subclases y, por tanto, el acoplamiento entre ellas Implementacin del patrn Strategy

DCTI

Patrones de Diseo de Software

Alda Pascuzzo-Lima

USB


Las posibles estrategias se ejecutan dentro de un objeto de contexto que se encarga de recuperar la estrategia apropiada para el cliente. Cada una de las estrategias implementa una interfaz que define la firma del mtodo de la estrategia. Vamos a ver un ejemplo que permita aclarar esto. Por ejemplo, en un banco existen distintos tipos de cuentas, para las cules se siguen distintos algoritmos a la hora de calcular sus rendimientos anuales. Un objeto encargado de calcular los rendimientos de las cuentas (en este ejemplo, ste sera el objeto de contexto) podra utilizar distintas estrategias para calcular el rendimiento de cada tipo de cuenta. El diagrama muestra el ejemplo: Si ahora se quiere incluir un nuevo tipo de cuenta, por ejemplo Cuenta Vivienda, habra que crear una nueva estrategia que implemente el algoritmo de clculo de rendimiento y hacer que el objeto CalculadoraRendimiento relacione este tipo de cuenta con la estrategia adecuada. De esta forma, se desacopla el clculo del rendimiento especfico de cada tipo de cuenta, separando cada uno en una clase hacindolos ms claros de entender y ms fcilmente modificables. Otro ejemplo con la programacin en Java incluida: public abstract class EstrategiaDibujo extends JFrame { private float[ ] _x,_y; private Color _c; private int _ancho,_alto; public EstrategiaDibujo() { .... } public abstract void dibujar(float[ ] px, float[ ] py); } Lo importante de esta clase es que cada una de las estrategias que diseemos tendr que sobrescribir el mtodo dibujar() y proveer un algoritmo concreto para dicha estrategia. public class EstrategiaDibujoConcreta1 extends EstrategiaDibujo{ ... public void dibujar(float[ ] px, float[ ] py){ ... } ... }

DCTI


Alda Pascuzzo-Lima

USB


public class EstrategiaDibujoConcreta2 extends EstrategiaDibujo{ ... public void dibujar(float[ ] px, float[ ] py){ ... } ... } El Contexto es la clase que decide qu estrategia utilizar en cada momento, la decisin se puede realizar mediante algn parmetro que le enva el cliente aunque como hemos dicho puede ser l mismo el que elija la estrategia ms adecuada: public class CreadorDibujos { private EstrategiaDibujo _estrategia; private float[ ] _x,_y; public CreadorDibujos() { // Establecer estrategia por defecto. } public void establecerDibujoBarras() { estrategia = new EstrategiaDibujoBarras(); } public void establecerDibujoLineas() { estrategia = new EstrategiaDibujoLineas(); } .............. public void dibuja() { estrategia.dibujar(_x,_y); } } Sadda

DCTI


Alda Pascuzzo-Lima

USB


SINGLETON El patrn de diseo singleton (instancia nica) est diseado para restringir la creacin de objetos pertenecientes a una clase o el valor de un tipo a un nico objeto. Se cataloga como un patrn creacional. Su intencin consiste en garantizar que una clase slo tenga una instancia y proporcionar un punto de acceso global a ella. El patrn singleton se implementa creando en nuestra clase un mtodo que crea una instancia del objeto slo si todava no existe alguna. Para asegurar que la clase no puede ser instanciada nuevamente se regula el alcance del constructor (con atributos como protegido o privado). La instrumentacin del patrn puede ser delicada en programas con mltiples hilos de ejecucin. Si dos hilos de ejecucin intentan crear la instancia al mismo tiempo y esta no existe todava, slo uno de ellos debe lograr crear el objeto. La solucin clsica para este problema es utilizar exclusin mutua en el mtodo de creacin de la clase que implementa el patrn. Se observan dos caractersticas bsicas: 1. Restriccin de acceso al constructor. Con esto conseguimos que sea imposible crear nuevas instancias. Solo la propia clase puede crear la instancia. 2. Mecanismo de acceso a la instancia. El acceso a la instancia nica se hace a travs de un nico punto bien definido, que es gestionado por la propia clase y que puede ser accedido desde cualquier parte del cdigo (en principio). Veamos el cdigo en Java: public class Singleton { static private Singleton singleton = null; private Singleton() { } static public Singleton getSingleton() { if (singleton == null) { singleton = new Singleton(); } return singleton; } // Mtodos del singleton. public String metodo() { return "Singleton instanciado bajo demanda"; } }DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


Java No hay una sola forma de implementacin. Por ejemplo, para programas multi-hilo, una implementacin correcta en Java sera la solucin conocida como "inicializacin bajo demanda": public class Singleton { private static Singleton INSTANCE = new Singleton(); // El constructor privado no permite que se genere un constructor por defecto // (con mismo modificador de acceso que la definicin de la clase) private Singleton() {} public static Singleton getInstance() { return INSTANCE; } } Un ejemplo correcto de inicializacin diferida. public class Singleton { private static Singleton INSTANCE = null; // Private constructor suppresses private Singleton() {} // creador sincronizado para protegerse de posibles problemas multi-hilo // otra prueba para evitar instanciacin mltiple private synchronized static void createInstance() { if (INSTANCE == null) { INSTANCE = new Singleton(); } } public static Singleton getInstance() { createInstance(); return INSTANCE; } } Una implementacin del patrn singleton en Javascript es la siguiente: Javascrip Singleton = function Singleton$constructor() { return { getInstance : function Singleton$getInstance() { return this; } }; }(); Python Ahora un ejemplo de implementacin de Singleton en Python (pero no segura en programacin multi-hilo) class Singleton (object):DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


instance = None def __new__(cls, *args, **kargs): if cls.instance is None: cls.instance = object.__new__(cls, *args, **kargs) return cls.instance #Usage mySingleton1 = Singleton() mySingleton2 = Singleton() #mySingleton1 y mySingleton2 son la misma instancia assert mySingleton1 is mySingleton2 Otro ejemplo con la implementacin: Supongamos que estamos en un proyecto con varias personas. Nuestra aplicacin se conecta con un socket con otro programa que corre en algn lado. Alguien de nuestro proyecto hace la clase Conexion que dentro establece la conexin a travs de socket con el otro programa. A esta clase se le pone los mtodos enviaMensaje() y un avisameCuandoLLegueMensaje(), de forma que todo el mundo pueda enviar mensajes por la conexin y ser avisado cuando llegue algn mensaje en el que tenga inters. Todos los que necesitan esta Conexion deben poner en sus clases un mtodo tomaConexion() que reciba como parmetro la Conexion, y guardarsela para enviar mensajes o recibirlos. Adems, como es habitual, la documentacin de diseo no es lo suficientemente buena y alguno de nuestros programadores despistados, se olvida de poner el mtodo y decide simplemente hacer un new Conexion(). Por un lado tenemos el problema de pasar la Conexion a todos. Por otro lado, el programa funciona mal porque hay varias clases Conexion instanciadas y el otro programa piensa que somos varios clientes y la mensajera que recibimos no es del todo coherente (eso si no tenemos directamente problemas con la conexin al haber varios pelendose por la misma). El patrn Singleton ayuda a que la instancia Conexion sea nica, a la vez que la hace accesible a todo el mundo sin necesidad de andar pasndola. Vamos sin embargo a hacerlo siguiendo el patrn estrategia. Creemos una clase que implemente. Para ello debemos hacer varias cosas: La clase Conexion debe tener un constructor privado, de forma que nadie, salvo ella misma, pueda instanciarla. La clase Conexion debe tener un atributo esttico privado, inicialmente a null. En l se guardar la nica instancia de esta clase. La clase Conexion debe tener un mtodo esttico pblico dameConexion(). Este mtodo crea una instancia de Conexion la primera vez que se le llama y la guarda en el atributo estatico. Luego devuelve dicho atributo esttico en el return. Algo as: public class Conexion { private Conexion() { ...DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


} private static Conexion laConexion = null; public Conexion dameConexion() { if (laConexion == null) laConexion = new Conexion(); return laConexion; } } Cuando alguien necesita una conexion, simplemente debe hacer Conexion miConexion = Conexion.dameConexion(); y tiene accesible la nica instancia de Conexion que hay. FACTORY METHOD En diseo de software, el patrn de diseo Factory Method consiste en utilizar una clase constructora (al estilo del Abstract Factory) abstracta con unos cuantos mtodos definidos y otro(s) abstracto(s): el dedicado a la construccin de objetos de un subtipo de un tipo determinado. Es un patrn creacional. Es una simplificacin del Abstract Factory, en la que la clase abstracta tiene mtodos concretos que usan algunos de los abstractos; segn usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento. Abstract Factory permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se est usando. Es un patrn creacional. Estructura Las clases principales en este patrn son el creador y el producto. El creador necesita crear instancias de productos, pero el tipo concreto de producto no debe ser forzado en las subclases del creador, porque entonces las posibles subclases del creador deben poder especificar subclases del producto para utilizar.

DCTI


Alda Pascuzzo-Lima

USB


La solucin para esto es hacer un mtodo abstracto (el mtodo de la fbrica) que se define en el creador. Este mtodo abstracto se define para que devuelva un producto. Las subclases del creador pueden sobrescribir este mtodo para devolver subclases apropiadas del producto. Ejemplo en Java:// Definimos la clase abstracta constructora public abstract class Creator{ // Operacin que realiza public Product anOperation() { return factoryMethod(); } // Definimos mtodo abstracto protected abstract Product factoryMethod(); } //Ahora definimos el creador concreto. public class ConcreteCreator extends Creator{ protected Product factoryMethod() { return new ConcreteProduct(); } } //Definimos el producto y su implementacin concreta. public interface Product{ public void operacion(); } public class ConcreteProduct implements Product{ public void operacion(){ System.out.println("Una operacin de este producto"); } } Y un ejemplo de uso: public static void main(String args[]){ Creator aCreator; aCreator = new ConcreteCreator(); Product producto = aCreator.factoryMethod(); producto.operacion(); }

Relacin entre patrones: Los patrones no existen aislados el uno del otro, sino ms bien dentro del contexto de un lenguaje o sistema de patrones. Por consiguiente existen relaciones entre ellos que pueden determinar cundo, cmo y por qu utilizar uno u otro. Los patrones deDCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


fabricacin no estn exentos de esto. Un ejemplo que tiene Factory, Strategy y Singleton: Se plante el problema: Queremos cambiar el sistema actual de autenticacin de nuestra aplicacin (por Base de Datos), pero no tenemos claro an que sistema final utilizar: LDAP o MQSeries. Para la implementacin prctica de la solucin al problema planteado en el patrn estrategia, haremos uso de otros dos patrones de diseo: Los patrones strategy, factory, y singleton. Lo primero que haremos, ser crear un interface al que llamaremos IAutenticacion.java: A continuacin, crearemos las clases que realizan la validacin en los tres posibles sistemas finales que el cliente puede elegir, y haremos que implementen las tres el interfaz: AutenticacionBBDD.java

AutenticacionLDAP.java

AutenticacionMQ.java

DCTI


Alda Pascuzzo-Lima

USB


En esta situacin, si no hicisemos caso de nuestro patrn estrategia, lo que haramos sera que en nuestro cdigo de validacin, haramos algo similar a esto: Si estamos validando por MQ: AutenticacionMQ mq = new AutenticacionMQ(); mq.autentica(login,clave); Si estamos validando por LDAP: AutenticacionLDAP ldap = new AutenticacionLDAP(); ldap.autentica(login,clave); Si estamos validando en BBDD: AutenticacionBBDD bbdd = new AutenticacionBBDD(); bbdd.autentica(login,clave); Cada vez que se cambie la forma de validarse, tendremos que hacer un pase a produccin con la modificacin adecuada en cada caso. Vamos sin embargo a hacerlo siguiendo el patrn estrategia. Creemos una clase que implemente el patrn de diseo Factoria de Objetos. La llamaremos FactoriaAutenticacion.java:

DCTI


Alda Pascuzzo-Lima

USB


En la clase, hemos creado un mtodo que crea un objeto del tipo deseado, en funcin de una entrada en un fichero de propiedades. Adems, la factora interesa que sea singleton (para asegurar que slo haya una instancia de ellas en la aplicacin). Para ello, modificaremos nuestra clase de la siguiente manera:

Una vez en este punto, tan slo debemos cambiar el cdigo en el que queremos validar (mostrados anteriormente) por este otro:

Ahora, cuando se cambie la forma de validacin, tan solo debemos cambiar la clase que usaremos para validar en el fichero de propiedades mencionado anteriormente, sin la necesidad de realizar un pase nuevo a produccin: Si es por BBDD clase.autenticadora = com.autentia.tutoriales.estrategia.AutenticacionBBDD Si es por LDAP clase.autenticadora = com.autentia.tutoriales.estrategia.AutenticacionLDAP Si es por MQ Series clase.autenticadora = com.autentia.tutoriales.estrategia.AutenticacionMQ DECORATOR El patrn Decorator responde a la necesidad de aadir dinmicamente funcionalidad a un Objeto. Esto nos permite no tener que crear sucesivas clases que hereden de la primera incorporando la nueva funcionalidad, sino otras que la implementan y se asocian a la primera. Es un patrn estructural.DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


Su intencin es decorar las responsabilidades de un objeto dinmica y transparentemente a sus clientes. Alternativa a la herencia para decorar la responsabilidad de un subconjunto de objetos Motivacin: Ejemplo explosin de herencia con extensiones repetidas: cafs con distintos condimentos Necesidad de cambiar las extensiones en tiempo de ejecucin Repeticin de cdigo Reutilizacin Participantes: 1. AbstractComponent: Supertipo de los objetos que pueden ser decorados 2. ConcreteComponent: define un objeto susceptible de ser decorado 3. AbstractDecorator: permite distintos decoradores en diferentes combinaciones, sin tener que derivar una clase para cada combinacin posible. 4. Decorator1 -DecoratorN: decora una o varias operaciones de un ConcreteComponent El decorador redirige sus mensajes sobre un objeto de tipo AbstractComponent. Opcionalmente, puede invocar mtodos adicionales antes y despus de la redireccin. Ventajas e Inconvenientes: Mayor flexibilidad que la herencia, incluso puede decorarse un objeto varias veces con el mismo decorador, lo que sera imposible con la herencia Cifrar doblemente un texto Favorece la definicin de interfaces y clases bases ligeras. Slo se carga con las funcionalidades que se necesitan. No son necesarias megaclases que sean capaces de hacerlo todo Cuidado: ha de respetarse la interfaz. Por ejemplo, se podra aadir la posibilidad de exportar el contenido del archivo asociado al Tracer? Incremento de pequeos objetos. Ms difciles de entender y de depurar.

Mantener ligera AbstractComponent. Facilita la implementacin de los decoradores La decoracin es recurrente y en general no es conmutativa El ConcreteComponent puede establecerse en el constructor del decorador o posteriormente mediante operaciones Get/SetDecorable.

DCTI


Alda Pascuzzo-Lima

USB


Ejemplo en Java:abstract class Componente{ abstract public void operacion(); } class ComponenteConcreto extends Componente{ public void operacion(){ System.out.println("ComponenteConcreto.operacion()"); } } abstract class Decorador extends Componente{ protected Componente componente; public void setComponente(Componente component){ this.componente = component; } public void operacion(){ if (componente != null) componente.operacion(); } } class DecoradorConcretoA extends Decorador{ private String estadoAgregado; public void operacion(){ super.operacion(); estadoAgregado = "Nuevo estado"; System.out.println("DecoradorConcretoA.operacion()"); } } class DecoradorConcretoB extends Decorador{ public void operacion(){ super.operacion(); agregarComportamiento(); System.out.println("DecoradorConcretoB.operacion()"); } void agregarComportamiento(){ System.out.println("comportamiento aadido B"); } } public class Cliente{ public static void main(String[] args){ ComponenteConcreto c = new ComponenteConcreto(); DecoradorConcretoA d1 = new DecoradorConcretoA(); DecoradorConcretoB d2 = new DecoradorConcretoB(); d1.setComponente(c); d2.setComponente(d1); d2.operacion(); } }

OBSERVER Es un patrn de diseo que define una dependencia del tipo uno-a-muchos entre objetos, de manera que cuando uno de los objetos cambia su estado, notifica este cambio a todos los dependientes. Se trata de un patrn de comportamiento, es decir, est relacionado con algoritmos de funcionamiento y asignacin de responsabilidades a clases y objetos. Los patrones de comportamiento describen no solamente estructuras de relacin entre objetos o clases sino tambin esquemas de comunicacin entre ellos.DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


Este patrn tambin se conoce como el patrn de publicacin-inscripcin o modelo-patrn. Estos nombres sugieren las ideas bsicas del patrn, que son bien sencillas: el objeto de datos, llammoslo Sujeto a partir de ahora, contiene atributos mediante los cuales cualquier objeto observador o vista se puede suscribir a l pasndole una referencia a s mismo. El Sujeto mantiene as una lista de las referencias a sus observadores. Los observadores a su vez estn obligados a implementar unos mtodos determinados mediante los cuales el Sujeto es capaz de notificar a sus observadores suscritos los cambios que sufre para que todos ellos tengan la oportunidad de refrescar el contenido representado. De manera que cuando se produce un cambio en el Sujeto, ejecutado, por ejemplo, por alguno de los observadores, el objeto de datos puede recorrer la lista de observadores avisando a cada uno. Este patrn suele observarse en los frameworks de interfaces grficas orientados a objetos, en los que la forma de capturar los eventos es suscribir listeners a los objetos que pueden disparar eventos. Participantes de forma desglosada: 1. Sujeto (Subject): El sujeto concreto proporciona una interfaz para agregar (attach) y eliminar (detach) observadores. El Sujeto conoce a todos sus observadores. 2. Observador (Observer): Define el mtodo que usa el sujeto para notificar cambios en su estado (update/notify). 3. Sujeto Concreto (ConcreteSubject): Mantiene el estado de inters para los observadores concretos y los notifica cuando cambia su estado. No tienen por qu ser elementos de la misma jerarqua. 4. Observador Concreto (ConcreteObserver): Mantiene una referencia al sujeto concreto e implementa la interfaz de actualizacin, es decir, guardan la referencia del objeto que observan, as en caso de ser notificados de algn cambio, pueden preguntar sobre este cambio. Consecuencias de usar este patrn: Las consecuencias de aplicar este patrn pueden ser tanto beneficiosas como pueden perjudicar algunos aspectos. Por una parte abstrae el acoplamiento entre el sujeto y el observador, lo cual es beneficioso ya que conseguimos una mayor independencia y adems el sujeto no necesita especificar los observadores afectados por un cambio. Por otro lado, con el uso de este patrn ocurre que vamos a desconocer las consecuencias de una actualizacin, lo cual, dependiendo del problema, puede afectarnos en mayor o menor medida (por ejemplo, al rendimiento).

DCTI


Alda Pascuzzo-Lima

USB


Ejemplo en Java:/*Esta clase abstracta representa los objetos susceptibles de ser observados. * Incorpora mtodos para agregar y eliminar observadores y un mtodo de * notificacin. La asociacin Observable-Observadores se implementa mediante un * vector de observadores */ import java.util.ArrayList; public abstract class Observable { //El constructor crea el vector con la asociacion Observable-Observador public Observable() { _observadores = new ArrayList(); } //Agregar y eliminar sencillamente operan sobre vector _observadores... public void agregarObservador(Observador o) { _observadores.add(o); } public void eliminarObservador(Observador o) { _observadores.remove(o); } //Notificacion: Para cada observador se invoca el metodo actualizar(). public void notificarObservadores() { for (Observador o:_observadores) { o.actualizar(); } } //Este atributo privado mantiene el vector con los observadores private ArrayList _observadores; } /*Los observadores deben implementar la siguiente interfaz, es decir, *tienen un metodo actualizar() para reaccionar a cambios del sujeto */ public interface Observador { public void actualizar(); } /*Ejemplo de sujeto observable. Es una clase que mantiene un valor entero en *el rango 0..mximo, donde mximo se establece en la construccin. La clase *dispone de mtodos para modificar el valor y para acceder al estado *(valor, mximo). Extiende la clase observable heredando su */ public class Contador extends Observable { /*El constructor inicializa el estado del objeto: el maximo y el *valor inicial, siempre en el rango 0..maximo. Adicionalmente, *inicializa la parte de Observable que tiene un Contador... DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB */ public Contador(int valor, int maximo) { super(); _maximo = maximo; _valor = enRango(valor); } //Este mtodo privado asegura que un valor n esta entre 0..maximo private int enRango(int n) { if (n < 0) { return 0; } else if (n > _maximo) { return _maximo; } else { return n; } } //Estos dos mtodos permiten el acceso al estado del contador public int valor() { return _valor; } public int maximo() { return _maximo; }


/*Este mtodo afecta al estado: primero se modifica de forma consistente *el estado y despus se notifica a los observadores del cambio */ public void incrementarContador(int n) { _valor = enRango(_valor+n); notificarObservadores(); } //Atributos privados que mantienen el estado del contador private int _valor, _maximo; } // Observador muy simple que ni siquiera consulta el estado del sujeto... public class Detector implements Observador { public void actualizar() { System.out.println("Detector recibe actualizar!"); } } //Un ejemplo de observador concreto de la clase contador. public class Medidor implements Observador { //El constructor de Medidor establece la asociacin entre Medidor-Contador public Medidor(Contador contador) { _contador = contador; } DCTI Patrones de Diseo de Software Alda Pascuzzo-Lima

USB


/*Tras ser notificado de un cambio, un observador Medidor accede *al estado del Contador utilizando la asociacin */ public void actualizar() { int porcentaje = _contador.valor() * 100 / _contador.maximo(); System.out.println("Porcentaje del contador es " + porcentaje + "%"); } //Mantiene la asociacion con el contador private Contador _contador; } //Un ejemplo de observador concreto de la clase contador. public class ValorContador implements Observador { //El constructor establece la asociacion entre ValorContador-Contador public ValorContador(Contador contador) { _contador = contador; } /*Tras ser notificado de un cambio, un observador ValorContador accede *al estado del Contador utilizando la asociacion */ public void actualizar() { System.out.println("Valor del contador es " + _contador.valor() ); } //Mantiene asociacion con el sujeto observable private Contador _contador; } public class Main { public static void main(String... argv) { Contador c = new Contador(0,255); Detector d = new Detector(); c.agregarObservador(d); c.incrementarContador(5); ValorContador v = new ValorContador(c); c.agregarObservador(v); c.incrementarContador(5); Medidor m = new Medidor(c); c.agregarObservador(m); c.eliminarObservador(d); c.incrementarContador(19); } }

DCTI


Alda Pascuzzo-Lima

USB


Patrones creacionalesObject Pool (no pertenece a los patrones especificados por GoF): se obtienen objetos nuevos a travs de la clonacin. Utilizado cuando el costo de crear una clase es mayor que el de clonarla. Especialmente con objetos muy complejos. Se especifica un tipo de objeto a crear y se utiliza una interfaz del prototipo para crear un nuevo objeto por clonacin. El proceso de clonacin se inicia instanciando un tipo de objeto de la clase que queremos clonar. Abstract Factory (fbrica abstracta): permite trabajar con objetos de distintas familias de manera que las familias no se mezclen entre s y haciendo transparente el tipo de familia concreta que se est usando. Factory Method (mtodo de fabricacin): centraliza en una clase constructora la creacin de objetos de un subtipo de un tipo determinado, ocultando al usuario la casustica para elegir el subtipo que crear. Builder (constructor virtual): abstrae el proceso de creacin de un objeto complejo, centralizando dicho proceso en un nico punto. Prototype (prototipo): crea nuevos objetos clonndolos de una instancia ya existente. Singleton (instancia nica): garantiza la existencia de una nica instancia para una clase y la creacin de un mecanismo de acceso global a dicha instancia.

Patrones estructuralesAdapter (Adaptador): Adapta una interfaz para que pueda ser utilizada por una clase que de otro modo no podra utilizarla. Bridge (Puente): Desacopla una abstraccin de su implementacin. Composite (Objeto compuesto): Permite tratar objetos compuestos como si se tratara de uno simple. Decorator (Envoltorio): Aade funcionalidad a una clase dinmicamente. Facade (Fachada): Provee de una interfaz unificada simple para acceder a una interfaz o grupo de interfaces de un subsistema. Flyweight (Peso ligero): Reduce la redundancia cuando gran cantidad de objetos que poseen idntica informacin. Proxy: Mantiene un representante de un objeto. Modulo: Agrupa varios elementos relacionados, como clases, singletons, y mtodos, utilizados globalmente, en una entidad nica.

Patrones de comportamientoChain of Responsibility (Cadena de responsabilidad): Permite establecer la lnea que deben llevar los mensajes para que los objetos realicen la tarea indicada. Command (Orden): Encapsula una operacin en un objeto, permitiendo ejecutar dicha operacin sin necesidad de conocer el contenido de la misma. Interpreter (Intrprete): Dado un lenguaje, define una gramtica para dicho lenguaje, as como las herramientas necesarias para interpretarlo. Iterator (Iterador): Permite realizar recorridos sobre objetos compuestos independientemente de la implementacin de estos. Mediator (Mediador): Define un objeto que coordine la comunicacin entre objetos de distintas clases, pero que funcionan como un conjunto. Memento (Recuerdo): Permite volver a estados anteriores del sistema. Observer (Observador): Define una dependencia de uno-a-muchos entre objetos, de forma que cuando un objeto cambie de estado se notifique y actualicen automticamente todos los objetos que dependen de l. State (Estado): Permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. Strategy (Estrategia): Permite disponer de varios mtodos para resolver un problema y elegir cul utilizar en tiempo de ejecucin. Template Method (Mtodo plantilla): Define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos, esto permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar su estructura. Visitor (Visitante): Permite definir nuevas operaciones sobre una jerarqua de clases sin modificar las clases sobre las que opera.

DCTI


Alda Pascuzzo-Lima

Documents

Patrones de Diseño de Software