patrones de diseño - ozarate.net · recurrentes de diseño de software. el concepto de patrones de...
TRANSCRIPT
PATRONES DE DISEÑO
El concepto promovido por Alexander fue retomado en el software y popularizado en el libro “Design Patterns: Elements of Reusable Object Oriented Software” . Debido a que son cuatro autores, a este libro también se le conoce como el “Gang of Four” (GoF). En el GoF se documentan 23 patrones que son soluciones conceptuales a problemas recurrentes de diseño de software. El concepto de patrones de diseño resultó extremadamente popular y después del GoF han aparecido una gran cantidad de libros de patrones de diseño enfocados a temas específicos como pueden ser diseño de arquitecturas, creación de sistemas distribuidos, sistemas tolerantes a fallas, seguridad, integración de sistemas, etcétera. Existen cientos de patrones de diseño documentados y una dificultad ahora es elegir patrones específicos de entre la gran variedad.
Articulo: Conceptos de Diseño Patrones, Tácticas y Frameworks (SG, 2013)
Mtro. Omar Zárate [email protected]
GANG OF FOUR
Autores: Erich Gamma, Ralph Johnson, Richard Helm, John Vlissides
Mtro. Omar Zárate [email protected]
PATRONES DE DISEÑO
8. Memento 9. Observer10. Builder11. Interpreter12. Command13. Factory Method14. Template Method15. Interpreter
1. Proxy2. Módulo3. Chain of Responsibility
4. Mediator 5. State6. Strategy7. Visitor8.Iterator
Mtro. Omar Zárate [email protected]
PATRONES DE DISEÑO
16. Abstract Factory17. Decorator18. Composite19. Singleton20. Bridge 21. Prototype22. Facade23. Adapter
Mtro. Omar Zárate [email protected]
Abstract FactoryDebemos crear diferentes objetos, todos pertenecientes a la misma familia. Por ejemplo: las bibliotecas para crear interfaces gráficas suelen utilizar este patrón y cada familia sería un sistema operativo distinto. Así pues, el usuario declara un Botón, pero de forma más interna lo que está creando es un BotónWindows o un BotónLinux, por ejemplo.
El problema que intenta solucionar este patrón es el de crear diferentes familias de objetos.
El patrón Abstract Factory 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.
Mtro. Omar Zárate [email protected]
Abstract FactoryLa estructura típica del patrón Abstract Factory es la siguiente:
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 la 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.
Mtro. Omar Zárate [email protected]
Abstract FactoryEjemplo:
Supongamos que disponemos de una cadena de pizzerías. Para crear pizzas disponemos de un método abstracto en la clase Pizzería que será implementada por cada subclase de Pizzería.
abstract Pizza crearPizza()
Concretamente se creará una clase PizzeríaZona por cada zona, por ejemplo la Pizzería de New York sería PizzeriaNewYork y la de Californía PizzeríaCalifornia que implementarán el método con los ingredientes de sus zonas.
Las pizzas son diferentes según las zonas. No es igual la pizza de New York que la pizza de California. Igualmente, aunque usarán los mismos ingredientes (tomate, mozzarella...) no los obtendrán del mismo lugar, cada zona los comprará donde lo tenga más cerca. Así pues podemos crear un método creador de Pizza que sea
Pizza (FactoriaIngredientes fi);
Mtro. Omar Zárate [email protected]
Abstract FactoryComo vemos utilizamos la factoría abstracta (no las concretas de cada zona, como podría ser IngredientesNewYork o IngredientesCalifornia). Pizza podrá obtener los ingredientes de la factoría independientemente de donde sea. Sería fácil crear nuevas factorías y añadirlas al sistema para crear pizzas con estos nuevos ingredientes. Efectivamente, en este ejemplo cliente es Pizza y es independiente de la Factoría usada.
El creador de la Pizza será el encargado de instanciar la factoría concreta, así pues los encargados de instanciar las factorías concretas serán las pizzerías locales. En PizzeríaNewYork podemos tener el método crearPizza() que realice el siguiente trabajo:
Mtro. Omar Zárate [email protected]
Abstract Factory
Como conclusión podemos observar que gracias a la factoría de ingredientes crear una nueva zona, por ejemplo una pizzería en Barcelona, no nos implicaría estar modificando el código existente, solo deberemos extenderlo (uno de los pilares de la Ingeniería del software) ya crearíamos la subclase de Pizzería: PizzeríaBarcelona que al instanciar la factoría solo debería escoger la factoría de Barcelona. Obviamente se debería crear la factoría de Barcelona que se encargaría de crear los productos obtenidos de Barcelona. Así que en ningún momento modificamos las pizzerías existentes, la superclase pizzería o las otras factorías o productos, solo creamos nuevas clases.
Mtro. Omar Zárate [email protected]
SingletonEn ingeniería de software, el patrón singleton (instancia única en inglés) es un patrón de diseño diseñado para restringir la creación de objetos pertenecientes a una clase o el valor de un tipo a un único objeto.
Su intención consiste en garantizar que una clase sólo tenga una instancia y proporcionar un punto de acceso global a ella.
El patrón singleton 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 modificadores de acceso como protegido o privado).
La instrumentación del patrón puede ser delicada en programas con múltiples hilos de ejecución. Si dos hilos de ejecución intentan crear la instancia al mismo tiempo y esta no existe todavía, sólo uno de ellos debe lograr crear el objeto. La solución clásica para este problema es utilizar exclusión mutua en el método de creación de la clase que implementa el patrón.
Mtro. Omar Zárate [email protected]
Singleton
Las situaciones más habituales de aplicación de este patrón son aquellas en las que dicha clase controla el acceso a un recurso físico único (como puede ser el ratón o un archivo abierto en modo exclusivo) o cuando cierto tipo de datos debe estar disponible para todos los demás objetos de la aplicación.
El patrón singleton provee una única instancia global gracias a que:
• La propia clase es responsable de crear la única instancia.• Permite el acceso global a dicha instancia mediante un método de clase.• Declara el constructor de clase como privado para que no sea instanciable
directamente.
Mtro. Omar Zárate [email protected]
Prototype
El patrón de diseño 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.
Dicho de otro modo, este patrón propone la creación de distintas variantes de objetos que nuestra aplicación necesite, en el momento y contexto adecuado. Toda la lógica necesaria para la decisión sobre el tipo de objetos que usará la aplicación en su ejecución se hace independiente, de manera que el código 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.
Mtro. Omar Zárate [email protected]
Prototype
En el caso, por ejemplo, de un editor gráfico, podemos crear rectángulos, círculos, etc... como copias de prototipos. Estos objetos gráficos pertenecerán a una jerarquía cuyas clases derivadas implementarán el mecanismo de clonación.
Mtro. Omar Zárate [email protected]
Prototype
Cliente: Es el encargado de solicitar la creación de los nuevos objetos a partir de los prototipos.
Prototipo Concreto: Posee 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.
Mtro. Omar Zárate [email protected]
Facade
El patrón fachada viene motivado por la necesidad de estructurar un entorno de programación y reducir su complejidad con la división en subsistemas, minimizando las comunicaciones y dependencias entre éstos.
Se aplicará el patrón fachada cuando se necesite proporcionar una interfaz simple para un subsistema complejo, o cuando se quiera estructurar varios subsistemas en capas, ya que las fachadas serían el punto de entrada a cada nivel. Otro escenario proclive para su aplicación surge de la necesidad de desacoplar un sistema de sus clientes y de otros subsistemas, haciéndolo más independiente, portable y reutilizable (esto es, reduciendo dependencias entre los subsistemas y los clientes).
Mtro. Omar Zárate [email protected]
Facade
Fachada (Facade): conoce qué clases del subsistema son responsables de una determinada petición, y delega esas peticiones de los clientes a los objetos apropiados del subsistema.
Subclases (ModuleA, ModuleB, ModuleC...): implementan la funcionalidad del subsistema. Realizan el trabajo solicitado por la fachada. No conocen la existencia de la fachada.
Mtro. Omar Zárate [email protected]
AdapterEl patrón Adapter (Adaptador) se utiliza para transformar una interfaz en otra, de tal modo que una clase que no pudiera utilizar la primera, haga uso de ella a través de la segunda.
Convierte la interfaz de una clase en otra interfaz que el cliente espera. Adapterpermite a las clases trabajar juntas, lo que de otra manera no podría hacerlo debido a sus interfaces incompatibles.
Usar el patrón Adapter cuando:
• Se desea usar una clase existente, y su interfaz no se iguala con la necesitada.• Cuando se desea crear una clase reusable que coopera con clases no
relacionadas, es decir, las clases no tienen necesariamente interfaces compatibles.
Mtro. Omar Zárate [email protected]
Adapter
• Target define la interfaz específica del dominio que Client usa.• Client colabora con la conformación de objetos para la interfaz Target.• Adaptee define una interfaz existente que necesita adaptarse• Adapter adapta la interfaz de Adaptee a la interfaz Target
Mtro. Omar Zárate [email protected]