PATRONES DE DISEÑO

A lo largo de los años diseñadores con experiencia en programación orientada a objetos han desarrollado soluciones que sirven para resolver ciertos problemas. Estas soluciones generalmente consisten de un conjunto de clases relacionadas mediante herencia, composición o delegación, denominadas patrones de diseño. Si se dispone de un conjunto suficientemente completo de patrones de diseño (que abarquen la mayoría de los problemas que usualmente encuentra el diseñador) se cuenta con una herramienta poderosa para el diseño de software orientado a objetos. Patrones de diseño

En este caso el mecanismo de diseño consiste en identificar cual patrón de diseño sirve para resolver determinado problema. Una vez que se ha determinado cual patrón de diseño se debe usar, éste determina las clases y objetos que se requieren Patrones de diseño

Un patrón tiene cuatro elementos esenciales:  El nombre del patrón: consiste en una o dos palabras que podemos usar para describir un problema de diseño, sus soluciones y consecuencias.  El problema: describe cuando aplicar el patrón. Explica el problema y su contexto.  La solución: describe los elementos que constituyen el diseño, sus relaciones, responsabilidades y colaboradores.  La solución no describe un diseño o implementación en particular. Es una plantilla que puede ser aplicada en muchas situaciones diferentes. Patrones de diseño

Un patrón tiene cuatro elementos esenciales:  Las consecuencias: son los resultados de aplicar el patrón.  Generalmente tienen que ver con que el programa resultante sea más o menos eficiente tanto en velocidad de ejecución como en memoria utilizada. También tienen que ver con la flexibilidad, transportabilidad y facilidad de extender el programa. Patrones de diseño

Ejemplo: Suponga que se desea desarrollar una aplicación con interfaz de usuario gráfica (GUI), que sea fácil de portar a dos sistemas operativos: Windows y MacIntosh. Las GUI tienen una serie de objetos, generalmente conocidos como Widgets, tales como: ScrollBar, List, Button, etc. Se presenta el problema de que la apariencia (look and feel) de estos objetos es diferente en cada sistema operativo. La aplicación debe poder crear los objetos con la apariencia apropiada para cada sistema operativo.

Para crear un Widget se puede usar la instrucción new: ScrollBar sb = new WindowsScrollBar(); Si se desea un ScrollBar para el MacIntosh la operación es diferente: ScrollBar sb = new MacScrollBar(); Si se crean muchos Widgets (como suele ocurrir en aplicaciones de cierta complejidad) será muy difícil cambiar de un "look and feel" a otro, dado que hay que modificar muchas instrucciones que están diseminadas por diferentes partes del programa Patrones de diseño

Este problema se puede solucionar con el patrón de diseño conocido como Fábrica Abstracta. Una fábrica es un objeto que se encarga de crear otros objetos. Los elementos de este patrón son:  Una fábrica abstracta y varias subclases que representan las fábricas concretas  Un producto abstracto y varias subclases que representan los productos concretos Patrones de diseño

Para la aplicación GUI se tiene: Una fábrica abstracta denominada GUIFactory, Dos fábricas concretas: WindowsFactory (crea Widgets con apariencia “Windows”) y MacFactory (crea Widgets con Apariencia “MacIntosh”). Patrones de diseño GUIFactory createScrollBar() createButton() createMenu() WindowsFactory createScrollBar() createButton() createMenu() MacFactory createScrollBar() createButton() createMenu()

Los productos son los Widgets. Se necesita una clase Widget (el producto abstracto) y varias subclases que correspondientes a los diferentes elementos de una GUI: ScrollBar, Button, Menu, etc: Patrones de diseño Widget ScrollBar scrollTo() WindowsScrollBar scrollTo() Button press() Menu popUp() MacScrollBar scrollTo()

Para crear un ScrollBar en lugar de invocar la operación new directamente: ScrollBar sb = new WindowsScrollBar(); Podemos invocar la fábrica: ScrollBar sb = guiFactory.createScrollBar(); La variable guiFactory debe ser inicializada al comienzo del programa con una de las fábricas concretas: GUIFactory guiFactory = new MacFactory(); Patrones de diseño

Descripción de patrones de diseño Nombre del patrón y clasificación Propósito. ¿Qué hace el patrón?. ¿Para qué sirve?. Qué problemas de diseño resulte? Otros nombres Justificación Aplicabilidad. En que situaciones se debe utilizar. En que situaciones no se debe utilizar. Estructura. Representación gráfica (UML) Participantes. Clases y objetos que participan y sus responsabilidades Consecuencias. Rendimiento, facilidad de mantenimiento... Patrones de diseño

Implementación. Consejos, técnicas, asuntos específicos de algunos lenguajes Código ejemplo Ejemplos de uso Patrones relacionados Patrones de diseño

¿Qué problemas resuelven los patrones de diseño? Encontrar objetos apropiados Determinar la granularidad de los objetos Especificar las interfaces de los objetos Especificar las implementaciones de los objetos (Clases) Implementar mecanismos de reutilización de código Herencia versus Composición Delegación Patrones de diseño

Tipos de patrones Patrones creacionales Patrones estructurales Patrones de comportamiento

Patrones de diseño Patrones creacionales Ayudan a que un sistema sea independiente de cómo sus objetos son creados Patrones creacionales de clase. Usan herencia para variar las clases que son instanciadas Patrones creacionales de objeto. Delegan la creación de objetos a otros objetos Los patrones creacionales contienen conocimiento de qué clases concretas el sistema usa Esconden la forma en que los objetos son creados

Patrones de diseño Lo único que el sistema total conoce de los objetos son sus interfaces Dan flexibilidad con respecto a Qué es creado Quién crea los objetos Cómo se crean y cuándo La configuración puede ser estática (en tiempo de compilación) o dinámica (en tiempo de ejecución) Pueden ser competidores o pueden complementarse

Patrones de diseño Ejemplo: construir un laberinto para un juego enter() Room WallDoor Maze enter() setSide() getSide() roomNumber enter() enter() isOpen MapSite

Patrones de diseño public class MapSite { public abstract void enter() } public class Room extends mapsite() { private MapSite sides[4]; private int roomNumber; public Room(int roomNo) {... } public MapSite getSide(Direction dir) {... } public void setSide(Direction dir, MapSite site) {... }; }

Patrones de diseño public class Wall extends MapSite { public void enter() {... } } public class Door extends Mapsite() { public Door(Room r1, Room r2) {... } public void enter() {... } public Room otherSideFrom(Room r) {... } private Room room1; private Room room2; private boolean isOpen; }

public class Maze { public Maze() {... } public void addRoom(Room r) {... } public Room RoomNo(int n) {... } private... ;... }

Public class MazeGame { Maze createMaze() { Maze aMaze = new Maze(); Room r1 = new Room(1); Room r2 = new Room(2); Door theDoor = new Door(r1, r2); aMaze.addRoom(r1); aMaze.addRoom(r2); r1.setSide(Direction.North, new Wall()); r1.setSide(Direction.East, theDoor); r1.setSide(Direction.South, newWall); r1.setSide(direction.West, new Wall); r2.setSide(Direction.North, new Wall()); r2.setSide(Direction.East, new Wall); r2.setSide(Direction.South, newWall); r2.setSide(direction.West, theDoor); return aMaze; }

Patrones creacionales Abstrac Factory Propósito. Proveer una interfaz para crear familias de objetos relacionados sin especificar sus clases concretas Otros nombres. Kit Motivación. Ejemplo de interfaces de usuario.

Patrones creacionales Aplicabilidad. Usar este patrón cuando Un sistema debe ser independiente de como sus productos son creados, compuestos y representados Un sistema debe ser configurado con una de múltiples familias de productos Una familia de objetos relacionados está diseñada para ser usados conjuntamente Se desea proveer una biblioteca de clases de productos y sólo se desea revelar sus interfaces, no sus implementaciones

Patrones creacionales Estructura AbstracFactory createProductA() createProductB() createProductC() ConcreteFactory2 createProductA() createProductB() createProductC() ConcreteFactory1 createProductA() createProductB() createProductC() AbstracProductA ProductA1 ProductA2 AbstracProductB ProductB1ProductB2

Patrones creacionales Participantes Abstract Factory (WidgetFactory) ConcreteFactory (WindowsFactory, MacFactory) AbstractProduct (ScrollBar, Menu) ConcreteProduct(WindowsScrollBar, WindowsMenu) Client

Patrones creacionales Colaboraciones Normalmente se crea una única instancia de una clase concreta en tiempo de ejecución. Esta fábrica crea objetos que tienen determinada interfaz. Para crear objetos diferentes se usar una fábrica diferente Fábrica abstracta difiere la creación de objetos a las subclases concretas.

Patrones creacionales Consecuencias Aísla las clases concretas. Hace fácil cambiar de familia de productos Promueve la consistencia entre productos Es difícil soportar nuevos tipos de productos

Patrones creacionales Implementación Se puede implementar la fábrica como un singleton Creación de productos. La fabrica abstracta solo declara la interfaz de los productos Usar el patrón FactoryMethod Colocar en los métodos create un parámetro que indique lo que se desea crear

Patrones creacionales Singleton Propósito. Asegurar que una clase tiene una sola instancia y proveer un punto global de acceso a la misma Motivación. Hay casos en que solo debe haber un objeto de una clase: print spooler, file system, window manager Aplicabilidad. Usar cuando Debe haber exactamente una instancia de una clase Cuando la única instancia debe ser extendible y los clientes deben ser capaces de usar la instancia extendida sin modificar el código

Patrones creacionales Estructura Singleton static instance() singletonOperation() getSingletonData() static uniqueInstance singletonData

Patrones creacionales Participantes. Singleton Define una operación “instance” que permite a los clientes acceder a la única instancia Puede ser responsable de crear su única instancia Colaboraciones Los clientes acceden a la instancia única a través de la operación “instance”

Patrones creacionales Consecuencias Acceso controlado a la instancia única Espacio de nombres reducido (no se requieren variables globales) Permite refinamiento de operaciones y representación. La clase se puede extender. Más flexible que las operaciones de clase (métodos estáticos).

Patrones creacionales Implementación Class Singleton { private static Singleton instance=null; public static Singleton instance() { if (instance == null) { instance = new Singleton(); } return instance; } protected Singleton() {} }

Patrones creacionales Factory method Propósito. Definir una interfaz para crear objetos, dejando que las subclases decidan que clase instanciar. Motivación Aplicabilidad. Usar cuando Una clase no puede anticipar la clase de objetos que debe crear Se necesita que las subclases especifiquen los objetos a ser creados

Patrones creacionales Estructura Producto operacion() ProductoConcreto operacion() Creator factoryMethod() CreadorConcreto factoryMethod()

Patrones creacionales Participantes Producto ProductoConcreto Creador CreadorConcreto Colaboraciones El patrón Creator delega en las subclases la creación de los objetos.

Patrones creacionales Consecuencias Eliminan la necesidad de especificar las clases de los objetos creados El código solo trabaja con interfaces Desventaja. Es posible que los clientes tengan que crear una subclase de creador solo para crear un objeto

Patrones creacionales Implementación Posibles implementaciones El creador es una clase abstracta El creador es una clase concreta Métodos fábrica parametrizados

Patrones creacionales Builder Propósito. Separar la construcción de un objeto complejo de su representación de manera que el mismo proceso de construcción pueda crear diferentes representaciones Motivación. Ejemplo: una aplicación que convierte texto RTF a diferentes formatos: texto ascii, TeX, TextWidget.

Patrones creacionales Estructura

Patrones creacionales Aplicabilidad. Usar cuando El algoritmo para crear un objeto complejo debe ser independiente de las partes que constituyen el objeto y su ensamblaje El proceso de construcción debe permitir representaciones diferentes del objeto construido. Participantes Builder (TextConverter) ConcreteBuilder (ASCIIConverter, TeXConverter,...) Director (RTFReader). Product (ASCIIText, TeXText)

Patrones creacionales Colaboraciones El cliente crea el objeto Director y lo configura con el constructor (builder deseado) El director le notifica al constructor cada vez que se debe construir una parte del producto El constructor procesa solicitudes del director y agrega partes al producto El cliente obtiene el producto del constructor

Patrones creacionales Consecuencias Permite variar la representación interna del producto El objeto constructor provee al director con una interfaz para construir el producto. Permite aíslar el código de construcción y representación Permite un control fino del proceso de construcción. Los objetos son construidos paso por paso. Cuando el proceso termina el producto es retribuido

Patrones creacionales Implementación Típicamente hay una clase abstracta Builder (o interfaz) que define una operación para crear cada componente. Las clases concretas sobrecargan esas operaciones. No hay clase abstracta para el producto debido a que éstos pueden variar mucho

Patrones creacionales Prototype Propósito. Especificar los tipos de objetos a ser creados usando un prototipo. Crear nuevos objetos clonando el prototipo Motivación

Patrones creacionales Aplicabilidad. Usar cuando Las clases a instanciar se especifican en tiempo de ejecución Para evitar una jerarquía de fábricas paralelas a la jerarquía de productos

Patrones creacionales Estructura

Patrones creacionales Participantes Prototype Concrete prototype Client Colaboraciones Un cliente solicita a un prototipo que se clone a si mismo

Patrones creacionales Consecuencias Consecuencias similares a AbstractFactory Se pueden agregar y eliminar productos en tiempo de ejecución Menos uso de herencia Permite configurar una aplicación con clases dinámicamente.