Programación de aplicaciones-Patrones de Diseño

PROGRAMACIÓN DE APLICACIONES

Instructor : Nataniel Marcial Chavez

10.07.11 Programación de aplicaciones

I I I . PATRONES DE DISEÑO.

10.07.11 Programación de aplicaciones

P R O G R A M A C I Ó N D E A P L I C A C I O N ES

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11

Programación de aplicaciones

Cuando construimos una pieza de software, desde un pequeño utilitario, hasta un sistema completo distribuido, estamos encarando un trabajo de análisis, diseño y desarrollo. Esa actividad puede realizarse en grupo o individualmente. En muchas situaciones, hemos notado que la implementación de una solución, en un caso de diseño o de programación, es similar a otra que hemos adoptado en el pasado. También suele suceder que descubrimos, más adelante, que la solución adoptada para un problema en particular, sea opacada por otra solución no contemplada inicialmente. Cuantas veces nos "despertamos" a una nueva alternativa de implementación, al ver el código o el esquema de la solución de otro producto. Es común encontrar también pistas e ideas interesantes en los artículos y libros que vamos consultando.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Siendo la creación de software, una actividad humana que se viene desarrollando desde hace décadas, no es extraño que hayan surgido esquemas de soluciones a problemas planteados anteriormente. Y, ante tanta "crisis del software", (el siempre presente problema de generar soluciones en tiempo y costo), esta situación ha incentivado la aparición de metodologías de análisis, de diseño, de implementación, y de manejo de proyectos.

En el agitado mundo de estas metodologías (reflejo de los perpetuos cambios a los que nos tiene acostumbrada nuestra profesión), a fines del siglo pasado, surge el concepto de "Patterns" (patrones).

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Un pequeño ejemplo

El patrón resulta ser una solución a un problema, que se puede aplicar muchas veces, en distintas situaciones. Veamos un caso en particular. Supongamos que tenemos una clase SistemaDeFacturacion, que concentra la actividad de generar facturas. Queremos que el resto del sistema, interactúe con una sola instancia de esta clase, porque es importante para nosotros no generar recursos duplicados, y controlar el acceso a los mismos. ¿Cómo podemos conseguir este resultado? Podemos escribir el código:

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


public class SistemaDeFacturacion { //NOTA: Sólo para aplicaciones de un thread private static SistemaDeFacturacion _Instancia = null; private SistemaDeFacturacion() { } public static SistemaDeFacturacion GetInstancia() { if (_Instancia==null) { _Instancia = new SistemaDeFacturacion (); } return _Instancia; } //... otras funciones de Sistema de Facturacion }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Algo de historia

Curiosamente, el concepto de patrón de diseño, no nace en el software, sino en otra actividad, en la arquitectura .Como la nuestra, esta actividad se dedica a construir, y no es extraño que comparta vocabulario y conceptos. Christopher Alexander es el arquitecto que primero estudió el concepto de pattern, en el contexto de construcción de edificios y comunidades. El escribió, ya en 1977: "Cada pattern describe un problema que ocurre una y otra vez en nuestro entorno, y además, describe el núcleo de la solución a ese problema, de tal manera, que podemos usar esa solución un millón de veces más en el tiempo, sin que tenga que ser la misma cada vez" El escribía acerca de patterns en la arquitectura, pero lo que describe, se puede aplicar a la ingeniería del software. Expresaremos nuestra solución en términos de objetos e interfaces, en lugar de usar paredes, espacios y edificios. Pero al fin, usaremos mismos principios para expresar un pattern.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


A fines de los ochenta, el término "software architecture" era ya usado normalmente, y en las reuniones de especialistas, iba naciendo la idea de un manual para arquitectos de sistemas, una especie de guía o hasta enciclopedia, de las prácticas habituales en la construcción de sistemas. Ya había habido algún antecendente ilustre, como el conocido "The Art of Computer Programming" del notable Donald Knuth. Su intento de catalogar el conocimiento acumulado sobre la programación, estuvo centrado en los algoritmos. Aún hoy es la referencia sobre algunos de esos temas. Algunas otras publicaciones habían tratado otros aspectos. El libro seminal de Coplien "Advanced C++: Programming Styles and Idioms", mostró ciertas soluciones específicas a C++, por ejemplo, una que permitía construir una clase String (tan necesaria en un lenguaje que derivaba de C, donde el concepto de string como tipo primitivo no existía), de una forma eficiente.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Por otra rama, en la de desarrollo en Smalltalk (más que un lenguaje o una tecnología, un ambiente de objetos), se comienzan a describir patrones, soluciones que ya se habían aplicado en problemas anteriores, notablemente en la propia librería base del lenguaje (como el caso del notify en Object, preludio de los actuales Observer). El mítico Kent Beck tuvo la idea de difundir el trabajo de Alexander, tan alejado al principio del software, entre la comunidad smalltalker, desde su columna en "The Smalltalk Report". Peter Coad también trabaja en esos tiempos en coleccionar patrones. En un escrito de 1992, "Object Oriented Patterns", en las comunicaciones de la asociación ACM (Association for Computer Machinery, http://www.acm.org), comienza a presentar el uso de patrones en las etapas de análisis y diseño.

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

http://www.acm.org/

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Pero es con el trabajo de Gamma, Helm, Johnson, Vlissides, "Design Patterns", en 1995, subtitulado "Elementos de software orientado a objetos reusable", cuando el tema se pone maduro. Estos autores, conocidos afectuosamente como "GoF" (la "Gang of Four", la banda de los cuatro), son los que toman el trabajo algo monumental, de hacer un catálogo de los patrones de diseño que hasta ese momento habían aparecido, y en una lista de 23 patterns, tratan de enumerar el conocimiento acumulado sobre el tema. Este libro, se ha convertido en un escrito de culto para los estudiosos, y realmente se lo merece, por el orden y la claridad y extensión de su exposición.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Anteriormente, hemos encontrado una cita de Alexander, donde menciona que un pattern, es "la solución a un problema". Según "GoF" un patrón tendrá entonces, cuatro elementos esenciales:

El nombre: Este elemento, que alguien podría pensar que es intrascendente, o trivial, ha probado que ser fundamental. A cada patrón popular, se le ha asignado una denominación que permite que los entendidos en el tema, puedan conversar usando un diccionario común. Nos permite un mayor grado de abstracción. Nos permite comunicarnos con nuestros colegas, construir un lenguaje compartido, y hasta nos ayuda a nosotros mismos, al ordenar un patrón bajo un nombre. Según "GoF", uno de los problemas que tuvieron, fue encontrar un nombre apropiado para cada patrón que catalogaron.

El problema: se explica el problema original, y su contexto. Puede describir desde detalles específicos, como algoritmos, o clases y estructuras que se han encontrado inflexibles a la hora de implementarse. Pero primero, todo patrón nace de un problema a solucionar.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


La solución: nos encontraremos, en nuestro estudio de los patrones, que cada uno es en realidad una solución a un problema, el elemento planteado arriba. Hasta puede que un mismo problema real, tenga dos soluciones parecidas, correspondientes a dos patrones (muchas veces pasa esto con el Abstract Factory, versus el Factory Method). Pero la elección seguramente recaerá en el patrón que mejor se adapte al contexto particular del problema que tengamos entre manos. Resaltemos que la solución que un patrón describe, no necesariamente es detallada al nivel de implementación, sino que provee una descripción abstracta, una enumeración de elementos y sus relaciones, para solucionar el problema planteado.

Las consecuencias: son los resultados de aplicar el patrón, los "trade-off", compromisos, que se tienen que aceptar al adoptar el mismo. Como dicen los americanos, "no free lunch", no hay almuerzos gratis, de alguna forma hay que pagar lo que aparece especialmente barato. En general, en software, la moneda de pago de pago es el espacio y el tiempo. A veces, un patrón nos soluciona un tema de espacio , a costa de una mayor complejidad en otra punta de nuestro desarrollo.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


vemos que un patrón siempre tiene un problema, y una solución. Pero también notemos, que los catálogos de patrones que han aparecido, destacan que los elementos clasificados, siempre son patrones que ya se han aplicado exitosamente con anterioridad. No se ha dado el caso de un patrón creado de la nada, o simplemente para engrosar el catálogo. Cada patrón que veamos en la literatura, se verá respaldado por aplicaciones anteriores. El trabajo del catalogador, ha sido descubrir la esencia del patrón, para poder describirlo en un nivel mayor de abstracción, y aprovechar así su poder en otros ámbitos y contextos parecidos.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Describiendo un Patron de Diseño

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


He aquí algunos un formato consistente, para describir un patrón, adoptado en el libro de Gamma: Nombre del patrón y clasificación Cada patrón tiene un nombre, y una categoría a la que pertenece. El "GoF" los clasifica en creacionales, estructurales y de conducta. Más sobre esta clasificación más adelante. Intención Nada se da en la nada, sino en un contexto. Cada patrón tiene una intención, una razón, una justificación, algo como "¿qué problema de diseño trata de abordar?" Otros nombres O el A.K.A. ("Alsa Known As") del patrón. Ahora menos usado, pero en su tiempo, los patrones habían surgido en distintos proyectos y tecnologías. Los primeros autores les dieron un nombre que no siempre coincidía. Estos otros nombres pueden ser enumerados en la descripción del patrón.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Motivación Más que la intención, esta parte describe un escenario: un problema en particular que aparece, y que ayuda a entender la descripción algo más abstracta del patrón genérico. Aplicación En qué situaciones puede ser aplicado un patrón. Pueden darse ejemplos de malos diseños, que pueden beneficiarse de la aplicación de este patrón en particular. Estructura La parte más conocida, luego del nombre. Se adopta un diagrama basado originariamente en la OMT ("Object Modeling Technique"), hoy se usa UML ("Unified Modeling Language", Lenguaje Unificado de Modelado). Si bien no se necesita entender al detalle esta notación, cuando aparezca, en este artículo daremos nociones de la misma. Partipantes La lista de las clases y objetos que participan del patrón de diseño, y las responsabilidades que tienen.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Colaboraciones Descripción de cómo los participantes colaborar para llevar a cabo sus responsabilidades en el patrón Consecuencias Explica cómo el patrón cumple con sus objetivos, y que compromisos se asumen. Implementación Esta es la parte que más puede variar, porque para cada patrón puede haber varias posibles implementaciones, incluso, diferentes implementaciones según la tecnología adoptada. Veremos que hasta puede haber sutiles diferencias entre una implementación y otra, ligadas, por ejemplo, al lenguaje de implementación. Código de ejemplo Los buenos de la "GoF", siempre nos dan código de ejemplo de cada patrón, por ejemplo, en Smalltalk o en C++. Han aparecido luego libros con patrones aplicados a Java, y comienzan a aparecer las implementaciones .Net.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Usos conocidos Un patrón no es tal, si no ha sido ya empleado en algún caso real. Se debe incluir por lo menos dos ejemplos conocidos de difentes ámbitos. Patrones relacionados Ya hemos apuntado que un patrón es una solución a un problema. Puede que haya problemas parecidos, que tengan más de una solución. De ahí que muchos patrones estén relacionados entre sí: como el caso del Proxy y del Adapter. Se trata de explicar acá cuáles son las similitudes y (no menos importante) las diferencias, entre patrones relacionados.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Clasificación de Patrones

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Gamma y sus colaboradores, se concentran en los patrones de diseño, y los clasifican en las categorías. Agreguemos un resumen de los patrones que encontraron en cada una.

Patrones Creacionales

Estructurales

De Conducta

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Patrones Creacionales

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Patrones Creacionales:("Creational Patterns") Abstraen el proceso de instanciación. Nos ayudan a independizar a un sistema, de cómo sus objetos son creados. En general, tratan de ocultar las clases y métodos concretos de creación, de tal forma que al variar su implementación, no se vea afectado el resto del sistema. Es común encontrar "competencia" entre estos patrones: hay más de un patrón a adoptar ante una situación. Hay varios ejemplos en .NET de aplicación de estos patrones. Podemos nombrar acá al WebRequest.Create, que nos devuelve un objeto de distintas clases, dependiendo de lo que le aportemos como parámetros en ejecución. Abstract Factory: Nos da una interface para crear objetos de alguna familia, sin especificar la clase en concreto. Builder: Separa la construcción de un objeto complejo, de su representación. De esa manera, el mismo proceso de construcción puede crear diferentes resultados Factory Method: Se define una interface para crear objetos, como en el Abstract Factory, pero se delega a las subclases implementar la creación en concreto. Prototype: Mediante una instancia prototípica, conseguimos otras instancias de ese objeto. Singleton: Nos consigue dar un solo objeto de la clase, en cualquier momento de la aplicación.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Estructurales: ("Structural Patterns") Se ocupan de cómo clases y objetos se agrupan, para formar estructuras más grandes. Podemos nombrar al clásico patrón Composite, que permite agrupar varios objetos como si fueran uno solo, y tratar al objeto compuesto de una forma similar al simple. El clásico ejemplo es el de una clase Arbol, donde cada Nodo no importa si es un NodoCompuesto o uno simple. Encontramos en .NET una aplicación de este patrón en el XmlDocument. Adapter: Permite convertir una interface de una clase, en otra, que es la esperada por algún cliente. Bridge: Desacopla una abstracción de su implementación en concreto. Luego, podemos cambiar la implementación, o la abstracción, sin cambiar la otra. Composite: Compone objetos en una estructura de árbol, donde los objetos compuestos se tratan de forma similar a los objetos simples. Decorator: Agrega responsabilidad a un objeto dinámicamente, dándonos una alternativa a la extensión de una clase, en lugar de usar subclases.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Facade: Provee una interface unificada a un conjunto de funciones de un subsistema. Es una interface de alto nivel, para facilitar el uso del subsistema. Flyweight: Permite compartir objetos, sin repetirlos en el sistema, eficientemente. Proxy: Provee un subrogado a otro objeto, para controlar el acceso al mismo.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


De Conducta: ("Behavioral Patterns") Más que describir objetos o clases, sino la comunicación entre ellos. Frecuentemente, describen las colaboraciones entre distintos elementos, para conseguir un objetivo. Como muestra, en .NET tenemos los Enumerator, que implementan el patrón Iterator, una forma de recorrer una lista o colección, sin afectar a este elemento. Chain of Responsability: Nos desacopla el enviador de un mensaje, de su receptor, permitiendo que haya varios objetos que tengan la oportunidad de manejar el requerimiento. Eso se consigue pasando el requerimiento por la cadena de objetos hasta llegar al encargado de atenderlo. Command: Encapsula el requerimiento a un objeto, permitiendo incluso el "undo" de la operación. Interpreter: Construye una representación de la gramática de un lenguaje, junto con su intérprete. Iterator: Nos da un modo de acceder a los elementos de un objeto colección o similar, sin exponer su estructura interna. Mediator: Permite la interacción de varios objetos, sin generar acoples fuertes en esas relaciones.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Memento: Sin necesitar entrar en la estructura interna de un objeto, permite capturar su estado, para, por ejemplo, poder restaurarlo más adelante. Observer: Define una relación uno a muchos, entre un objetos y otros que están interesados en sus cambios, de nuevo, sin caer en el acople entre los mismos. State: Permite a un objeto cambiar su conducta cuando cambia su estado interno, simulando que cambia de clase. Strategy: Define una familia de algoritmos, y los hace intercambiables. Template Method: Define el esqueleto de una operación, cuyas operaciones más básicas, quedan delegadas en subclases. Visitor: Nos permite recorrer una estructura (un árbol, por ejemplo), aplicando una operación a cada elemento.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Patron de Diseño Singleton

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Definición: Garantiza que una clase tiene solamente un caso y proporcione un punto global del acceso a él.

Frecuencia del uso: medio alto

Diagrama de Clases UML

Patrón de Diseño Singleton

Clases participantes Las clases y/o los objetos que participan en este patrón son: • Singleton (LoadBalancer)

• define una Operación de Instancia que deje a los clientes tener acceso a una única Instancia.

• Es responsable de crear y de mantener una única Instancia .

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


using System; namespace DoFactory.GangOfFour.Singleton.Structural { /// <summary> /// MainApp startup class for Structural /// Singleton Design Pattern. /// </summary> class MainApp { /// <summary> /// Entry point into console application. /// </summary> static void Main() { // Constructor is protected -- cannot use new Singleton s1 = Singleton.Instance(); Singleton s2 = Singleton.Instance(); // Test for same instance if (s1 == s2) { Console.WriteLine("Objects are the same instance"); } // Wait for user Console.ReadKey(); } }

/// <summary> /// The 'Singleton' class /// </summary> class Singleton { private static Singleton _instance; // Constructor is 'protected' protected Singleton() { } public static Singleton Instance() { // Uses lazy initialization. // Note: this is not thread safe. if (_instance == null) { _instance = new Singleton(); } return _instance; } } }

Caso Estrutural Singleton

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


A continuación se muestra el código de un ejemplo real demuestra el patrón del Singleton como a través del objeto de LoadBalancing. Solamente una instancia (el singleton) de la clase puede ser creado porque los servidores pueden venir dinámicamente online o fuera de línea y cada petición debe ir a través de un objeto que tiene conocimiento sobre el estado de la granja de servidores (web).

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// Singleton pattern -- Real World example using System; using System.Collections.Generic; using System.Threading; namespace DoFactory.GangOfFour.Singleton.RealWorld { /// <summary> /// MainApp startup class for Real-World /// Singleton Design Pattern. /// </summary> class MainApp { /// <summary> /// Entry point into console application. /// </summary> static void Main() { LoadBalancer b1 = LoadBalancer.GetLoadBalancer(); LoadBalancer b2 = LoadBalancer.GetLoadBalancer(); LoadBalancer b3 = LoadBalancer.GetLoadBalancer(); LoadBalancer b4 = LoadBalancer.GetLoadBalancer(); // Same instance? if (b1 == b2 && b2 == b3 && b3 == b4) { Console.WriteLine("Same instance\n"); }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// Load balance 15 server requests LoadBalancer balancer = LoadBalancer.GetLoadBalancer(); for (int i = 0; i < 15; i++) { string server = balancer.Server; Console.WriteLine("Dispatch Request to: " + server); } // Wait for user Console.ReadKey(); } } /// <summary> /// The 'Singleton' class /// </summary> class LoadBalancer { private static LoadBalancer _instance; private List<string> _servers = new List<string>(); private Random _random = new Random(); // Lock synchronization object private static object syncLock = new object(); // Constructor (protected)

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


protected LoadBalancer() { // List of available servers _servers.Add("ServerI"); _servers.Add("ServerII"); _servers.Add("ServerIII"); _servers.Add("ServerIV"); _servers.Add("ServerV"); } public static LoadBalancer GetLoadBalancer() { // Support multithreaded applications through // 'Double checked locking' pattern which (once // the instance exists) avoids locking each // time the method is invoked if (_instance == null) { lock (syncLock) { if (_instance == null) { _instance = new LoadBalancer(); } } } return _instance; }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// Simple, but effective random load balancer public string Server { get { int r = _random.Next(_servers.Count); return _servers[r].ToString(); } } } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


A continuacion se muestra el mismo codigo pero optimizado para .Net Utilizando caracteristicas mas especificas del lenguage.

Esta solución para .net nos ofrece : El Patrón Singleton simplemente usas un constructor privado y una variable estática de solo lectura que es inicializada al construirse la clase

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// Singleton pattern -- .NET optimized using System; using System.Collections.Generic; namespace DoFactory.GangOfFour.Singleton.NETOptimized { /// <summary> /// MainApp startup class for .NET optimized /// Singleton Design Pattern. /// </summary> class MainApp { /// <summary> /// Entry point into console application. /// </summary> static void Main() { LoadBalancer b1 = LoadBalancer.GetLoadBalancer(); LoadBalancer b2 = LoadBalancer.GetLoadBalancer(); LoadBalancer b3 = LoadBalancer.GetLoadBalancer(); LoadBalancer b4 = LoadBalancer.GetLoadBalancer(); // Confirm these are the same instance if (b1 == b2 && b2 == b3 && b3 == b4) { Console.WriteLine("Same instance\n"); } // Next, load balance 15 requests for a server LoadBalancer balancer = LoadBalancer.GetLoadBalancer(); for (int i = 0; i < 15; i++) { string serverName = balancer.NextServer.Name; Console.WriteLine("Dispatch request to: " + serverName); }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// Wait for user Console.ReadKey(); } } /// <summary> /// The 'Singleton' class /// </summary> sealed class LoadBalancer { // Static members are 'eagerly initialized', that is, // immediately when class is loaded for the first time. // .NET guarantees thread safety for static initialization private static readonly LoadBalancer _instance = new LoadBalancer(); // Type-safe generic list of servers private List<Server> _servers; private Random _random = new Random(); // Note: constructor is 'private' private LoadBalancer() { // Load list of available servers _servers = new List<Server> { new Server{ Name = "ServerI", IP = "120.14.220.18" }, new Server{ Name = "ServerII", IP = "120.14.220.19" }, new Server{ Name = "ServerIII", IP = "120.14.220.20" }, new Server{ Name = "ServerIV", IP = "120.14.220.21" }, new Server{ Name = "ServerV", IP = "120.14.220.22" }, }; }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


public static LoadBalancer GetLoadBalancer() { return _instance; } // Simple, but effective load balancer public Server NextServer { get { int r = _random.Next(_servers.Count); return _servers[r]; } } } /// <summary> /// Represents a server machine /// </summary> class Server { // Gets or sets server name public string Name { get; set; } // Gets or sets server IP address public string IP { get; set; } } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Patron de Diseño Factory Method

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Factory Method

Define una interfaz para crear un objeto, pero las subclases deciden clase instanciar. El Patron de diseño Factory Method permite a una clase aplazar la creación de instancias de las subclases

Frecuencia del uso: Alto

Diagrama de Clases UML

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Clases participantes

Las clases y / o objetos que participan en este modelo son: * Product (Page) define la interfaz de los objetos el factory method crea. * ConcreteProduct (SkillsPage, EducationPage, ExperiencePage) implementan la interfaz Product * Creator (Document) declara a factory method, que es el que devuelve un objeto del tipo de producto. Creator también puede definir una implementación predeterminada del factory method que devuelve un objeto ConcreteProduct por defecto. puede llamar al factory method para crear un objeto del Product. * ConcreteCreator (Report, Resume) reemplaza el factory method para devolver una instancia de un ConcreteProduct.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Este código estructurales demuestra la gran flexibilidad que ofrece Factory method en la creación de diferentes objetos. La clase abstracta puede proporcionar un objeto de forma predeterminada, pero cada subclase puede crear instancias de una versión extendida del objeto.

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


using System; using System.Collections; class MainApp { /// <summary> /// Entry point into console application. /// </summary> static void Main() { // An array of creators Creator[] creators = new Creator[2]; creators[0] = new ConcreteCreatorA(); creators[1] = new ConcreteCreatorB(); // Iterate over creators and create products foreach(Creator creator in creators) { Product product = creator.FactoryMethod(); Console.WriteLine("Created {0}", product.GetType().Name); } // Wait for user Console.Read(); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "Product" abstract class Product { } // "ConcreteProductA" class ConcreteProductA : Product { } // "ConcreteProductB" class ConcreteProductB : Product { } // "Creator" abstract class Creator { public abstract Product FactoryMethod(); } // "ConcreteCreator" class ConcreteCreatorA : Creator { public override Product FactoryMethod() { return new ConcreteProductA(); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "ConcreteCreator" class ConcreteCreatorB : Creator { public override Product FactoryMethod() { return new ConcreteProductB(); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


using System; using System.Collections; class MainApp { static void Main() { // Note: constructors call Factory Method Document[] documents = new Document[2]; documents[0] = new Resume(); documents[1] = new Report(); // Display document pages foreach (Document document in documents) { Console.WriteLine("\n" + document.GetType().Name+ "--"); foreach (Page page in document.Pages) { Console.WriteLine(" " + page.GetType().Name); } } Console.Read(); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "Product" abstract class Page { } // "ConcreteProduct" class SkillsPage : Page { } // "ConcreteProduct" class EducationPage : Page { } // "ConcreteProduct" class ExperiencePage : Page { } // "ConcreteProduct" class IntroductionPage : Page { } // "ConcreteProduct" class ResultsPage : Page { }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "ConcreteProduct" class ConclusionPage : Page { } // "ConcreteProduct" class SummaryPage : Page { } // "ConcreteProduct" class BibliographyPage : Page { } // "Creator" abstract class Document { private ArrayList pages = new ArrayList(); // Constructor calls abstract Factory method public Document() { this.CreatePages(); } public ArrayList Pages { get{ return pages; } } // Factory Method public abstract void CreatePages(); }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "ConcreteCreator" class Resume : Document { // Factory Method implementation public override void CreatePages() { Pages.Add(new SkillsPage()); Pages.Add(new EducationPage()); Pages.Add(new ExperiencePage()); } } // "ConcreteCreator" class Report : Document { // Factory Method implementation public override void CreatePages() { Pages.Add(new IntroductionPage()); Pages.Add(new ResultsPage()); Pages.Add(new ConclusionPage()); Pages.Add(new SummaryPage()); Pages.Add(new BibliographyPage()); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


using System; using System.Collections.Generic; class MainApp { static void Main() { // Note: document constructors call Factory Method List<Document> documents = new List<Document>(); documents.Add(new Resume()); documents.Add(new Report()); // Display document pages foreach (Document document in documents) { Console.WriteLine( document + "--" ); foreach (Page page in document.Pages) { Console.WriteLine(" " + page); } Console.WriteLine(); } Console.Read(); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "Product" abstract class Page { // Override. Display class name public override string ToString() { return this.GetType().Name; } } // "ConcreteProduct" class SkillsPage : Page { } // "ConcreteProduct" class EducationPage : Page { } // "ConcreteProduct" class ExperiencePage : Page { } // "ConcreteProduct" class IntroductionPage : Page { }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "ConcreteProduct" class ResultsPage : Page { } // "ConcreteProduct" class ConclusionPage : Page { } // "ConcreteProduct" class SummaryPage : Page { } // "ConcreteProduct" class BibliographyPage : Page { }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "Creator" abstract class Document { private List<Page> pages = new List<Page>(); // Constructor invokes Factory Method public Document() { this.CreatePages(); } // Property public List<Page> Pages { get{ return pages; } } // Factory Method public abstract void CreatePages(); // Override public override string ToString() { return this.GetType().Name; } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


// "ConcreteCreator" class Resume : Document { // Factory Method implementation public override void CreatePages() { Pages.Add(new SkillsPage()); Pages.Add(new EducationPage()); Pages.Add(new ExperiencePage()); } } // "ConcreteCreator" class Report : Document { // Factory Method implementation public override void CreatePages() { Pages.Add(new IntroductionPage()); Pages.Add(new ResultsPage()); Pages.Add(new ConclusionPage()); Pages.Add(new SummaryPage()); Pages.Add(new BibliographyPage()); } }

PR

OG

RA

MA

CIÓ

N D

E AP

LICA

CIO

NES

Patrones de diseño

10.07.11


Programación de aplicaciones-Patrones de Diseño

Documents

Transcript of Programación de aplicaciones-Patrones de Diseño