EJEMPLOS DE PATRONES:

Patrones creacionales

Abstract Factory
Un ejemplo
Supongamos que disponemos de una cadena de pizzeras. Para crear pizzas disponemos de un mtodo abstracto en la clase Pizzera que ser implementada por cada subclase de Pizzera. abstract Pizza crearPizza() Concretamente se crear una clase PizzeraZona por cada zona, por ejemplo la Pizzera de New York sera PizzeriaNewYork y la de Californa PizzeraCalifornia que implementarn el mtodo con los ingredientes de sus zonas. Las pizzas son diferentes segn las zonas. No es igual la pizza de New York que la pizza de California. Igualmente, aunque usarn los mismos ingredientes (tomate, mozzarella...) no los obtendrn del mismo lugar, cada zona los comprar donde lo tenga ms cerca. As pues podemos crear un mtodo creador de Pizza que sea Pizza(FactoriaIngredientes fi); Como vemos utilizamos la factora abstracta (no las concretas de cada zona, como podra ser IngredientesNewYork o IngredientesCalifornia). Pizza podr obtener los ingredientes de la factora independientemente de donde sea. Sera fcil crear nuevas factoras y aadirlas al sistema para crear pizzas con estos nuevos ingredientes. Efectivamente, en este ejemplo cliente es Pizza y es independiente de la Factora usada. El creador de la Pizza ser el encargado de instanciar la factora concreta, as pues los encargados de instanciar las factoras concretas sern las pizzeras locales. En PizzeraNewYork podemos tener el mtodo crearPizza() que realice el siguiente trabajo: Pizza crearPizza() { FactoraIngredientes fi = new IngredientesNewYork(); Pizza pizza = new Pizza(fi); // Uso de la factora pizza.cortar(); pizza.empaquetar(); return pizza; } Como conclusin podemos observar que gracias a la factora de ingredientes crear una nueva zona, por ejemplo una pizzera en Barcelona, no nos implicara estar modificando el cdigo existente, solo deberemos extenderlo (uno de los pilares de la Ingeniera del software) ya crearamos la subclase de Pizzera: PizzeraBarcelona que al instanciar la factora solo debera escoger la factora de Barcelona. Obviamente se debera crear la factora de Barcelona que se encargara de crear los productos obtenidos de Barcelona. As que en ningn momento modificamos las pizzeras existentes, la superclase pizzera o las otras factoras o productos, solo creamos nuevas clases.

Prototype
Este patrn resulta til en escenarios donde es preciso abstraer la lgica que decide qu tipos de objetos utilizar una aplicacin, de la lgica que luego usarn esos objetos en su ejecucin. Los motivos de esta separacin pueden ser variados, por ejemplo, puede ser que la aplicacin deba basarse en alguna configuracin o parmetro en tiempo de ejecucin para decidir el tipo de objetos que se debe crear. En ese caso, la aplicacin necesitar crear nuevos objetos a partir de modelos. Estos modelos, o prototipos, son clonados y el nuevo objeto ser una copia exacta de los mismos, con el mismo estado. Como decimos, esto resulta interesante para crear, en tiempo de ejecucin, copias de objetos concretos inicialmente fijados, o tambin cuando slo existe un nmero pequeo de combinaciones diferentes de estado para las instancias de una clase. Dicho de otro modo, este patrn propone la creacin de distintas variantes de objetos que nuestra aplicacin necesite, en el momento y contexto adecuado. Toda la lgica necesaria para la decisin sobre el tipo de objetos que usar la aplicacin en su ejecucin se hace independiente, de manera que el cdigo que utiliza estos objetos solicitar una copia del objeto que necesite. En este contexto, una copia significa otra instancia del objeto. El nico requisito que debe cumplir este objeto es suministrar la funcionalidad de clonarse. En el caso, por ejemplo, de un editor grfico, podemos crear rectngulos, crculos, etc... como copias de prototipos. Estos objetos grficos pertenecern a una jerarqua cuyas clases derivadas implementarn el mecanismo de clonacin.

Patrones estructurales

ADAPTER

Ejemplo El patrn Adapter permite a clases incompatibles trabajar de manera conjunta mediante la conversin de la interfaz de una de las clases a la interfaz esperada por el cliente. Las llaves de tubo son un ejemplo claro de Adapter. Un zcalo se adhiere a un trinquete siempre que el amao de la unidad sea la misma. Los tamaos tpicos en Estados Unidos son 1/2" y 1/4". Obviamente, un trinquete de 1/2" no se adhiere a una unidad de 1/4" a menos que un adaptador sea usado. Unadaptador de 1/2" a 1/4" posee una conexin hembra de 1/2" para que quepa en el trinquete de 1/2" y una conexin macho de 1/4" para que quepa en la unidad.

DECORATOR Ejemplo Supongamos que tenemos una clase existente Ventana y queremos aadirle funcionalidad para que muestre un borde alrededor. Podemos crear una subclase VentanaConBorde que herede de Ventana. Hasta aqu todo bien, pero supongamos que surge la necesidad de crear una ventana que muestre un pequeo botn de ayuda con un signo de interrogacin (?) en su parte superior. Entonces tenemos las siguientes opciones: Crear otra subclase de Ventana: VentanaConBotnDeAyuda. Problema: No cubre la necesidad de tener ventanas con bordes y botn de ayuda a la vez. Crear una subclase de VentanaConBorde: VentanaConBordeYBotonDeAyuda. Problema: No tenemos una ventana con botn de ayuda y sin borde. Crear clases para todas las combinaciones posibles de funcionalidades. Problema: Con este ejemplo tendramos cuatro clases: Ventana, VentanaConBorde, VentanaConBotonDeAyuda y VentanaConBordeYBotonDeAyuda; con tres funcionalidades tendramos ocho clases y con cuatro, diecisis!. Para n funcionalidades se necesitan 2n clases. Implementacin (Ejemplo) El patrn Decorator soluciona este problema de una manera mucho ms sencilla y extensible. Se crea a partir de Ventana la subclase abstracta VentanaDecorador y, heredando de ella, BordeDecorador y BotonDeAyudaDecorador. VentanaDecorador encapsula el comportamiento de Ventana y utiliza composicin recursiva para que sea posible aadir tantas "capas" de Decorators como se desee. Podemos crear tantos Decoradores como queramos heredando de VentanaDecorador.

Patrones de comportamiento
Iterator

Ejemplo
El patrn Iterator proporciona maneras de acceder a los elementos de un objeto contenedor (coleccin) de manera secuencial sin exponer la estructura del objeto. Los archivos son objetos similares a las colecciones. En oficinas en donde el acceso a los archivos es hecho a travs de administrativos o secretarias, el patrn Iterator es demostrado con la secretaria actuando comoIterator. Muchas comedias de televisin han sido creadas al rededor de la premisa de un ejecutivo tratando de entender el sistema de archivado de su secretaria. Para el ejecutivo, dicho sistema es confuso e ilgico, pero la secretaria es capaz de acceder a los archivos rpida y eficientemente. En viejos aparatos de televisin, un dial era utilizado para cambiar los canales. Para realizar zapping, el televidente deba girar dicho dial a travs de cada posicin que representaba un canal, independientemente de si ese canal tena o no seal. En los aparatos modernos, se utilizan los botones siguiente y previo. Cuando un televidente presiona el botn siguiente, se muestra al siguiente canal sintonizado. Consideremos estar mirando televisin en la habitacin de un hotel en una ciudad desconocida. Al navegar por los canales, el nmero del canal no es importante, pero el programa s lo es. Si el programa de un canal no resulta interesante, el televidente puede solicitar el siguiente canal, sin conocer el nmero.

Strategy

EJEMPLO Considera un sistema de comercio electrnico que soporta ventas en Estados Unidos, Mxico y Canad. En un futuro cercano, la base de clientes ser expandida para incluir pases de Sudamrica. El sistema debe saber cmo calcular el impuesto de la venta para los clientes de los tres pases, cada uno de los cuales tiene sus propias reglas para calcular el impuesto de la venta. El diseo del cdigo para calcular el impuesto de la venta debe ser flexible, de modo que resulte fcil agregar otros pases. En una solucin basada en el patrn de diseo Estrategia, el cdigo para calcular el impuesto de las ventas en Estados Unidos es encapsulado en su propia clase, al igual que el cdigo para Canad y Mxico

La interfaz TaxCalculator declara el mtodo calculateTax. Las clases que implementan la interfaz TaxCalculator acceden a definir el mtodo calculateTax. La complejidad del cdigo del impuesto de venta se reduce separndolo en tres clases.

Si se agrega un pas al sistema, se crea una nueva clase que encapsula las reglas del impuesto de ventas para dicho pas. La nueva clase implementa la interfaz TaxCalculator y defina su propia versin del mtodo calculateTax.