Programación de Aplicaciones-Patrones de Diseño

PROGRAMACIN DE APLICACIONES
Instructor : Nataniel Marcial Chavez
10.07.11
Programacin de aplicaciones
III. PATRONES DE DISEO.
10.07.11
10.07.11
Patrones de diseo
Cuando construimos una pieza de software, desde un pequeo utilitario, hasta un sistema completo distribuido, estamos encarando un trabajo de anlisis, diseo y desarrollo. Esa actividad puede realizarse en grupo o individualmente. En muchas situaciones, hemos notado que la implementacin de una solucin, en un caso de diseo o de programacin, es similar a otra que hemos adoptado en el pasado. Tambin suele suceder que descubrimos, ms adelante, que la solucin adoptada para un problema en particular, sea opacada por otra solucin no contemplada inicialmente. Cuantas veces nos "despertamos" a una nueva alternativa de implementacin, al ver el cdigo o el esquema de la solucin de otro producto. Es comn encontrar tambin pistas e ideas interesantes en los artculos y libros que vamos consultando.
10.07.11
Patrones de diseo
Siendo la creacin de software, una actividad humana que se viene desarrollando desde hace dcadas, no es extrao 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 situacin ha incentivado la aparicin de metodologas de anlisis, de diseo, de implementacin, y de manejo de proyectos. En el agitado mundo de estas metodologas (reflejo de los perpetuos cambios a los que nos tiene acostumbrada nuestra profesin), a fines del siglo pasado, surge el concepto de "Patterns" (patrones).
10.07.11
Patrones de diseo
Un pequeo ejemplo El patrn resulta ser una solucin 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, interacte con una sola instancia de esta clase, porque es importante para nosotros no generar recursos duplicados, y controlar el acceso a los mismos. Cmo podemos conseguir este resultado? Podemos escribir el cdigo:
10.07.11
Patrones de diseo
public class SistemaDeFacturacion { //NOTA: Slo 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 }
10.07.11
Patrones de diseo
Algo de historia
Curiosamente, el concepto de patrn de diseo, no nace en el software, sino en otra actividad, en la arquitectura .Como la nuestra, esta actividad se dedica a construir, y no es extrao que comparta vocabulario y conceptos. Christopher Alexander es el arquitecto que primero estudi el concepto de pattern, en el contexto de construccin de edificios y comunidades. El escribi, ya en 1977: "Cada pattern describe un problema que ocurre una y otra vez en nuestro entorno, y adems, describe el ncleo de la solucin a ese problema, de tal manera, que podemos usar esa solucin un milln de veces ms en el tiempo, sin que tenga que ser la misma cada vez" El escriba acerca de patterns en la arquitectura, pero lo que describe, se puede aplicar a la ingeniera del software. Expresaremos nuestra solucin en trminos de objetos e interfaces, en lugar de usar paredes, espacios y edificios. Pero al fin, usaremos mismos principios para expresar un pattern.
10.07.11
Patrones de diseo
A fines de los ochenta, el trmino "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 gua o hasta enciclopedia, de las prcticas habituales en la construccin de sistemas. Ya haba habido algn antecendente ilustre, como el conocido "The Art of Computer Programming" del notable Donald Knuth. Su intento de catalogar el conocimiento acumulado sobre la programacin, estuvo centrado en los algoritmos. An hoy es la referencia sobre algunos de esos temas. Algunas otras publicaciones haban tratado otros aspectos. El libro seminal de Coplien "Advanced C++: Programming Styles and Idioms", mostr ciertas soluciones especficas a C++, por ejemplo, una que permita construir una clase String (tan necesaria en un lenguaje que derivaba de C, donde el concepto de string como tipo primitivo no exista), de una forma eficiente.
10.07.11
Patrones de diseo
Por otra rama, en la de desarrollo en Smalltalk (ms que un lenguaje o una tecnologa, un ambiente de objetos), se comienzan a describir patrones, soluciones que ya se haban aplicado en problemas anteriores, notablemente en la propia librera base del lenguaje (como el caso del notify en Object, preludio de los actuales Observer). El mtico 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 tambin trabaja en esos tiempos en coleccionar patrones. En un escrito de 1992, "Object Oriented Patterns", en las comunicaciones de la asociacin ACM (Association for Computer Machinery, http://www.acm.org), comienza a presentar el uso de patrones en las etapas de anlisis y diseo.
10.07.11
Patrones de diseo
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 catlogo de los patrones de diseo que hasta ese momento haban 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 extensin de su exposicin.
10.07.11
Patrones de diseo
Anteriormente, hemos encontrado una cita de Alexander, donde menciona que un pattern, es "la solucin a un problema". Segn "GoF" un patrn tendr entonces, cuatro elementos esenciales:
El nombre: Este elemento, que alguien podra pensar que es intrascendente, o trivial, ha probado que ser fundamental. A cada patrn popular, se le ha asignado una denominacin que permite que los entendidos en el tema, puedan conversar usando un diccionario comn. Nos permite un mayor grado de abstraccin. Nos permite comunicarnos con nuestros colegas, construir un lenguaje compartido, y hasta nos ayuda a nosotros mismos, al ordenar un patrn bajo un nombre. Segn "GoF", uno de los problemas que tuvieron, fue encontrar un nombre apropiado para cada patrn que catalogaron. El problema: se explica el problema original, y su contexto. Puede describir desde detalles especficos, como algoritmos, o clases y estructuras que se han encontrado inflexibles a la hora de implementarse. Pero primero, todo patrn nace de un problema a solucionar.
10.07.11
Patrones de diseo
La solucin: nos encontraremos, en nuestro estudio de los patrones, que cada uno es en realidad una solucin 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 eleccin seguramente recaer en el patrn que mejor se adapte al contexto particular del problema que tengamos entre manos. Resaltemos que la solucin que un patrn describe, no necesariamente es detallada al nivel de implementacin, sino que provee una descripcin abstracta, una enumeracin de elementos y sus relaciones, para solucionar el problema planteado. Las consecuencias: son los resultados de aplicar el patrn, 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 patrn nos soluciona un tema de espacio , a costa de una mayor complejidad en otra punta de nuestro desarrollo.
10.07.11
Patrones de diseo
vemos que un patrn siempre tiene un problema, y una solucin. Pero tambin notemos, que los catlogos 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 patrn creado de la nada, o simplemente para engrosar el catlogo. Cada patrn que veamos en la literatura, se ver respaldado por aplicaciones anteriores. El trabajo del catalogador, ha sido descubrir la esencia del patrn, para poder describirlo en un nivel mayor de abstraccin, y aprovechar as su poder en otros mbitos y contextos parecidos.
10.07.11
Patrones de diseo
Describiendo un Patron de Diseo
10.07.11
Patrones de diseo
He aqu algunos un formato consistente, para describir un patrn, adoptado en el libro de Gamma: Nombre del patrn y clasificacin Cada patrn tiene un nombre, y una categora a la que pertenece. El "GoF" los clasifica en creacionales, estructurales y de conducta. Ms sobre esta clasificacin ms adelante. Intencin Nada se da en la nada, sino en un contexto. Cada patrn tiene una intencin, una razn, una justificacin, algo como "qu problema de diseo trata de abordar?" Otros nombres O el A.K.A. ("Alsa Known As") del patrn. Ahora menos usado, pero en su tiempo, los patrones haban surgido en distintos proyectos y tecnologas. Los primeros autores les dieron un nombre que no siempre coincida. Estos otros nombres pueden ser enumerados en la descripcin del patrn.
10.07.11
Patrones de diseo
Motivacin Ms que la intencin, esta parte describe un escenario: un problema en particular que aparece, y que ayuda a entender la descripcin algo ms abstracta del patrn genrico.
Aplicacin En qu situaciones puede ser aplicado un patrn. Pueden darse ejemplos de malos diseos, que pueden beneficiarse de la aplicacin de este patrn en particular. Estructura La parte ms 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 notacin, cuando aparezca, en este artculo daremos nociones de la misma. Partipantes La lista de las clases y objetos que participan del patrn de diseo, y las responsabilidades que tienen.
10.07.11
Patrones de diseo
Colaboraciones Descripcin de cmo los participantes colaborar para llevar a cabo sus responsabilidades en el patrn
Consecuencias Explica cmo el patrn cumple con sus objetivos, y que compromisos se asumen.
Implementacin Esta es la parte que ms puede variar, porque para cada patrn puede haber varias posibles implementaciones, incluso, diferentes implementaciones segn la tecnologa adoptada. Veremos que hasta puede haber sutiles diferencias entre una implementacin y otra, ligadas, por ejemplo, al lenguaje de implementacin. Cdigo de ejemplo Los buenos de la "GoF", siempre nos dan cdigo de ejemplo de cada patrn, por ejemplo, en Smalltalk o en C++. Han aparecido luego libros con patrones aplicados a Java, y comienzan a aparecer las implementaciones .Net.
10.07.11
Patrones de diseo
Usos conocidos Un patrn no es tal, si no ha sido ya empleado en algn caso real. Se debe incluir por lo menos dos ejemplos conocidos de difentes mbitos. Patrones relacionados Ya hemos apuntado que un patrn es una solucin a un problema. Puede que haya problemas parecidos, que tengan ms de una solucin. De ah que muchos patrones estn relacionados entre s: como el caso del Proxy y del Adapter. Se trata de explicar ac cules son las similitudes y (no menos importante) las diferencias, entre patrones relacionados.
10.07.11
Patrones de diseo
Clasificacin de Patrones
10.07.11
Patrones de diseo
Gamma y sus colaboradores, se concentran en los patrones de diseo, y los clasifican en las categoras. Agreguemos un resumen de los patrones que encontraron en cada una. Patrones Creacionales Estructurales De Conducta
10.07.11
Patrones de diseo
Patrones Creacionales
10.07.11
Patrones de diseo
Patrones Creacionales:("Creational Patterns") Abstraen el proceso de instanciacin. Nos ayudan a independizar a un sistema, de cmo sus objetos son creados. En general, tratan de ocultar las clases y mtodos concretos de creacin, de tal forma que al variar su implementacin, no se vea afectado el resto del sistema. Es comn encontrar "competencia" entre estos patrones: hay ms de un patrn a adoptar ante una situacin. Hay varios ejemplos en .NET de aplicacin de estos patrones. Podemos nombrar ac al WebRequest.Create, que nos devuelve un objeto de distintas clases, dependiendo de lo que le aportemos como parmetros en ejecucin. Abstract Factory: Nos da una interface para crear objetos de alguna familia, sin especificar la clase en concreto. Builder: Separa la construccin de un objeto complejo, de su representacin. De esa manera, el mismo proceso de construccin 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 creacin en concreto. Prototype: Mediante una instancia prototpica, conseguimos otras instancias de ese objeto. Singleton: Nos consigue dar un solo objeto de la clase, en cualquier momento de la aplicacin.
10.07.11
Patrones de diseo
Estructurales: ("Structural Patterns") Se ocupan de cmo clases y objetos se agrupan, para formar estructuras ms grandes. Podemos nombrar al clsico patrn Composite, que permite agrupar varios objetos como si fueran uno solo, y tratar al objeto compuesto de una forma similar al simple. El clsico ejemplo es el de una clase Arbol, donde cada Nodo no importa si es un NodoCompuesto o uno simple. Encontramos en .NET una aplicacin de este patrn en el XmlDocument. Adapter: Permite convertir una interface de una clase, en otra, que es la esperada por algn cliente. Bridge: Desacopla una abstraccin de su implementacin en concreto. Luego, podemos cambiar la implementacin, o la abstraccin, 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 dinmicamente, dndonos una alternativa a la extensin de una clase, en lugar de usar subclases.
10.07.11
Patrones de diseo
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.
10.07.11
Patrones de diseo
De Conducta: ("Behavioral Patterns") Ms que describir objetos o clases, sino la comunicacin entre ellos. Frecuentemente, describen las colaboraciones entre distintos elementos, para conseguir un objetivo. Como muestra, en .NET tenemos los Enumerator, que implementan el patrn Iterator, una forma de recorrer una lista o coleccin, 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 operacin. Interpreter: Construye una representacin de la gramtica de un lenguaje, junto con su intrprete. Iterator: Nos da un modo de acceder a los elementos de un objeto coleccin o similar, sin exponer su estructura interna. Mediator: Permite la interaccin de varios objetos, sin generar acoples fuertes en esas relaciones.
10.07.11
Patrones de diseo
Memento: Sin necesitar entrar en la estructura interna de un objeto, permite capturar su estado, para, por ejemplo, poder restaurarlo ms adelante. Observer: Define una relacin uno a muchos, entre un objetos y otros que estn 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 operacin, cuyas operaciones ms bsicas, quedan delegadas en subclases. Visitor: Nos permite recorrer una estructura (un rbol, por ejemplo), aplicando una operacin a cada elemento.
10.07.11
Patrones de diseo
Patron de Diseo Singleton
10.07.11
Patrones de diseo
Patrn de Diseo Singleton Definicin: 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
Clases participantes Las clases y/o los objetos que participan en este patrn son: Singleton (LoadBalancer) define una Operacin de Instancia que deje a los clientes tener acceso a una nica Instancia. Es responsable de crear y de mantener una nica Instancia .
10.07.11
Patrones de diseo
Caso Estrutural Singleton

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; } } }
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
A continuacin se muestra el cdigo de un ejemplo real demuestra el patrn del Singleton como a travs del objeto de LoadBalancing. Solamente una instancia (el singleton) de la clase puede ser creado porque los servidores pueden venir dinmicamente online o fuera de lnea y cada peticin debe ir a travs de un objeto que tiene conocimiento sobre el estado de la granja de servidores (web).
10.07.11
Patrones de diseo
// 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"); Programacin de aplicaciones }
10.07.11
Patrones de diseo
// 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)
10.07.11
Patrones de diseo
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; Programacin de aplicaciones }
10.07.11
Patrones de diseo
// Simple, but effective random load balancer public string Server { get { int r = _random.Next(_servers.Count); return _servers[r].ToString(); } } } }
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
A continuacion se muestra el mismo codigo pero optimizado para .Net Utilizando caracteristicas mas especificas del lenguage. Esta solucin para .net nos ofrece : El Patrn Singleton simplemente usas un constructor privado y una variable esttica de solo lectura que es inicializada al construirse la clase
10.07.11
Patrones de diseo
// 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); }
10.07.11
Patrones de diseo
// 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" }, }; }
10.07.11
Patrones de diseo
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; } } }
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
Patron de Diseo Factory Method
10.07.11
Patrones de diseo
Factory Method Define una interfaz para crear un objeto, pero las subclases deciden clase instanciar. El Patron de diseo Factory Method permite a una clase aplazar la creacin de instancias de las subclases Frecuencia del uso: Alto
Diagrama de Clases UML
10.07.11
Patrones de diseo
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 tambin puede definir una implementacin 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.
10.07.11
Patrones de diseo
Este cdigo estructurales demuestra la gran flexibilidad que ofrece Factory method en la creacin de diferentes objetos. La clase abstracta puede proporcionar un objeto de forma predeterminada, pero cada subclase puede crear instancias de una versin extendida del objeto.
10.07.11
Patrones de diseo
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(); } }
10.07.11
Patrones de diseo
// "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(); } }
10.07.11
Patrones de diseo
// "ConcreteCreator" class ConcreteCreatorB : Creator { public override Product FactoryMethod() { return new ConcreteProductB(); } }
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
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(); } }
10.07.11
Patrones de diseo
// "Product" abstract class Page { } // "ConcreteProduct" class SkillsPage : Page { } // "ConcreteProduct" class EducationPage : Page { } // "ConcreteProduct" class ExperiencePage : Page { } // "ConcreteProduct" class IntroductionPage : Page { } // "ConcreteProduct" class ResultsPage : Page { }
10.07.11
Patrones de diseo
// "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(); } Programacin de aplicaciones
10.07.11
Patrones de diseo
// "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()); } }
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
10.07.11
Patrones de diseo
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(); } }
10.07.11
Patrones de diseo
// "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 { }
10.07.11
Patrones de diseo
// "ConcreteProduct" class ResultsPage : Page { } // "ConcreteProduct" class ConclusionPage : Page { } // "ConcreteProduct" class SummaryPage : Page { } // "ConcreteProduct" class BibliographyPage : Page { }
10.07.11
Patrones de diseo
// "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; } }
10.07.11
Patrones de diseo
// "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()); } }
10.07.11
Patrones de diseo

Programación de Aplicaciones-Patrones de Diseño

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

Programación de Aplicaciones-Patrones de Diseño

Cargado por

Copyright:

Formatos disponibles

PROGRAMACIN DE APLICACIONES

Instructor : Nataniel Marcial Chavez

III. PATRONES DE DISEO.

Describiendo un Patron de Diseo

Patron de Diseo Singleton

Diagrama de Clases UML

Caso Estrutural Singleton

Patron de Diseo Factory Method

Diagrama de Clases UML

using System; using System.Collections;

También podría gustarte