Los patrones de diseño son soluciones probadas a problemas comunes de diseño de software. Se clasifican en creacionales, estructurales y de comportamiento. Los patrones creacionales incluyen el Singleton, que garantiza una única instancia de una clase, y el Object Pool, que reutiliza objetos para mejorar el rendimiento. El Factory Method y el Abstract Factory se encargan de la creación de objetos de forma flexible.

1. Patrones de Diseño Sergio David Fernández

2. Definición “Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software.” “Son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.” En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de software que están sujetos a contextos similares.

3. Objetivos Los patrones de diseño pretenden: Proporcionar catálogos de elementos reusables en el diseño de sistemas software. Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente. Formalizar un vocabulario común entre diseñadores. Estandarizar el modo en que se realiza el diseño. Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

4. Clasificación Patrones Creacionales: Inicialización y configuración de objetos. Patrones Estructurales: Separan la interfaz de la implementación. Se ocupan de cómo las clases y objetos se agrupan, para formar estructuras más grandes. Patrones de Comportamiento: Más que describir objetos o clases, describen la comunicación entre ellos.

5. Patrones Creacionales

6. Patrones Estructurales

7. Patrones de Comportamiento

8. Patrones Creacionales Abstraen el proceso de instanciación. Hacen al sistema independiente de las creaciones de objetos. Encapsulan conocimiento sobre las clases concretas usadas por el sistema. Ocultan la forma en que se crean y ponen en contacto las instancias. No son siempre excluyentes: a veces complementarios.

9. Singleton (Instancia Única) Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella. Todos los objetos que utilizan una instancia de una Clase Singleton utilizan la misma instancia.

10. Singleton (Instancia Única) Se implementa creando en nuestra clase un método que crea una instancia del objeto sólo si todavía 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).

11. Singleton (Instancia Única) Ventajas: Una clase Singleton puede controlar cómo y cuando el código cliente puede acceder a la única instancia. El código cliente no tiene la libertad de utilizar el operador new para crear instancias de la clase Singleton. En vez de eso, debe llamar a un método estático que regresa una referencia a la única instancia. Una clase Singleton puede ser modificada fácilmente si los requerimientos cambian y la aplicación necesita limitar el número de instancias a un número diferente de uno.

12. Object Pool (Conjunto de Objetos) El ObjectPooling (Agrupación de objetos), puede ofrecer un significativo aumento del rendimiento. Es eficaz en situaciones donde el costo de la inicialización de una instancia es alto, la tasa de creación de instancias es alta, y el número de instancias en uso en cualquier momento es bajo.

13. Object Pool (Conjunto de Objetos) Object Pools se utilizan para gestionar el almacenamiento en caché de objetos. Un cliente con acceso a un ObjectPool puede evitar la creación de nuevos objetos, simplemente preguntando al Pool por un uno que ya se ha instanciado. El manejo del Object Pool debe ser diseñado para ser una Clase Singleton, con el fin de que el Object Pool se encargue del manejo de los objetos.

14. Object Pool (Conjunto de Objetos) El funcionamiento es el siguiente: El Object Pool deja que se utilicen (checkout) objetos del Pool. Cuando no son más utilizados por el proceso que hizo el checkout, éstos son devueltos al Pool, con el fin de ser reutilizados. El Object Pool también instancia nuevos objetos cuando son requeridos (objetos se encuentran en uso), pero debe implementar una forma sencilla de limpiar objetos sin usar.

15. Builder (Constructor Virtual) Separa la construcción de un objeto complejo de su representación, de forma que el mismo proceso de construcción pueda crear diferentes representaciones.

16. Builder interfaz abstracta para crear productos. Concrete Builder implementación del Builder construye y reúne las partes necesarias para construir los productos Director construye un objeto usando el patrón Builder Producto El objeto complejo bajo construcción

17. Builder (Constructor Virtual) Ventajas Reduce el acoplamiento. Permite variar la representación interna de estructuras compleja, respetando la interfaz común de la clase Builder. Se independiza el código de construcción de la representación. Las clases concretas que tratan las representaciones internas no forman parte de la interfaz del Builder. Cada ConcreteBuilder tiene el código especifico para crear y modificar una estructura interna concreta. Distintos Director con distintas utilidades (visores, parsers, etc) pueden utilizar el mismo ConcreteBuilder. Permite un mayor control en el proceso de creación del objeto. El Director controla la creación paso a paso, solo cuando el Builder ha terminado de construir el objeto lo recupera el Director.

18. Builder (Constructor Virtual) Se debe usar cuando: El algoritmo para la creación de un objeto complejo debe ser independiente de las partes que conforman el objeto y cómo está montado. El proceso de construcción debe permitir diferentes representaciones del objeto que es construido.

19. FactoryMethod (Método de Fabricación) Define una interfaz para crear un objeto, pero deja que sean las subclases quienes decidan qué clase instanciar. Permite que una clase delegue en sus subclases la creación de objetos.

20. FactoryMethod (Método de Fabricación) Consiste en utilizar una clase constructora abstracta con unos cuantos métodos definidos y otro(s) abstracto(s): el dedicado a la construcción de objetos de un subtipo de un tipo determinado. Es una simplificación del AbstractFactory, en la que la clase abstracta tiene métodos concretos que usan algunos de los abstractos; según usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento.

21. Las clases principales en este patrón 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. La solución para esto es hacer un método abstracto (el método de la fábrica) que se define en el creador. Este método abstracto se define para que devuelva un producto. Las subclases del creador pueden sobrescribir este método para devolver subclases apropiadas del producto.

22. AbstractFactory (Fabrica Abstracta) Toma el mismo concepto de FactoryMethod pero al próximo nivel. En términos simples, un AbstractFactory es una clase que provee una interfaz para producir una familia de objetos relacionados o que dependen entre sí, sin especificar sus clases concretas. Se usa cuando se quiere retornar una de varias clases de objetos relacionados, cada uno de los cuales puede retornar varios diferentes objetos

23. AbstractFactory (Fabrica Abstracta) Está aconsejado cuando se prevé la inclusión de nuevas familias de productos, pero puede resultar contraproducente cuando se añaden nuevos productos o cambian los existentes, puesto que afectaría a todas las familias creadas.

24. AbstractFactory (Fabrica Abstracta)

25. AbstractFactory (Fabrica Abstracta) Cliente: La clase que llamará a la factoría adecuada ya que necesita crear uno de los objetos que provee la factoría, es decir, Cliente lo que quiere es obtener una instancia de alguno de los productos (ProductoA, ProductoB). AbstractFactory: Es de definición de la interfaces de las factorías. Debe de proveer un método para la obtención de cada objeto que pueda crear. ("crearProductoA()" y "crearProductoB()") Factorías Concretas: Estas son las diferentes familias de productos. Provee de la instancia concreta de la que se encarga de crear. De esta forma podemos tener una factoría que cree los elementos gráficos para Windows y otra que los cree para Linux, pudiendo poner fácilmente (creando una nueva) otra que los cree para MacOS, por ejemplo. Producto abstracto: Definición de las interfaces para la familia de productos genéricos. En el diagrama son "ProductoA" y "ProductoB". En un ejemplo de interfaces gráficas podrían ser todos los elementos: Botón, Ventana, Cuadro de Texto, Combo... El cliente trabajará directamente sobre esta interfaz, que será implementada por los diferentes productos concretos. Producto concreto: Implementación de los diferentes productos. Podría ser por ejemplo "BotónWindows" y "BotónLinux". Como ambos implementan "Botón" el cliente no sabrá si está en Windows o Linux, puesto que trabajará directamente sobre la superclase o interfaz.

26. Prototype (Prototipo) Tiene como finalidad crear nuevos objetos duplicándolos, clonando una instancia creada previamente. Este patrón especifica la clase de objetos a crear mediante la clonación de un prototipo que es una instancia ya creada. La clase de los objetos que servirán de prototipo deberá incluir en su interfaz la manera de solicitar una copia, que será desarrollada luego por las clases concretas de prototipos.

27. Prototype (Prototipo) La aplicación 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.

28. Cliente: Es el encargado de solicitar la creación de los nuevos objetos a partir de los prototipos. Prototipo Concreto: Posee una características concretas que serán reproducidas para nuevos objetos e implementa una operación para clonarse. Prototipo: Declara una interfaz para clonarse, a la que accede el cliente.

29. Bibliografía Qué es un patrón de diseño? http://msdn.microsoft.com/es-es/library/bb972240.aspx Patrón de diseño http://es.wikipedia.org/wiki/Patrón_de_diseño Object Pool DesignPatternhttp://sourcemaking.com/design_patterns/object_pool Patrones de diseño http://www.ingenierosoftware.com/analisisydiseno/patrones-diseno.php Builder – DesignPattern – GoFhttp://www.slideshare.net/jlrvpuma/builder-design-pattern-gof Builder (Patrón de diseño) http://es.wikipedia.org/wiki/Builder_(patr%C3%B3n_de_dise%C3%B1o)

30. Bibliografía Singletonhttp://es.wikipedia.org/wiki/Patr%C3%B3n_de_dise%C3%B1o_Singleton Patrón de diseño Singletonhttp://www.slideshare.net/lcahuich/2-3-5-patron-de-diseo-singular-singleton Patrones Creacionales http://www.slideshare.net/faustol/patrones-creacionales FactoryMethod (Patrón de diseño) http://es.wikipedia.org/wiki/Factory_Method_(patr%C3%B3n_de_dise%C3%B1o) AbstractFactoryhttp://www.slideshare.net/dialheca/abstract-factory AbstractFactory (Patrón de diseño) http://es.wikipedia.org/wiki/Abstract_Factory_(patr%C3%B3n_de_dise%C3%B1o)