Diseño De Patrones Explicados Simplemente

DISEÑO DE PATRONES EXPLICADOS SIMPLEMENTE

Alabado por los patrones de diseño. Este libro no es una introducción a la tecnología orientada a objetos o diseño. Muchos libros ya hacen un buen trabajo. Esto no es un tratado de avanzada. Es un libro de patrones de diseño que describe soluciones sencillas y elegantes a problemas específicos en el diseño de software orientado a objetos. ¡Una vez que comprenda los patrones de diseño y han tenido un “Aha!" (¿y no sólo un “huh?” experiencia con ellos, no volverás a pensar en el diseño orientado a objetos de la misma manera. Tendrás ideas que pueden hacer sus propios diseños más flexibles, modulares y reutilizables, y comprensible - que es porqué estás interesado en tecnología orientada a objetos, en primer lugar, ¿verdad?

Índice INDEX .................................................................................................... 5 OVERVIEW ........................................................................................... 6 ABSTRACT FACTORY....................................................................... 10 ADAPTER ........................................................................................... 14 BRIDGE ............................................................................................... 18 BUILDER ............................................................................................. 24 CHAIN OF RESPONSIBILITY ............................................................ 28 COMMAND .......................................................................................... 32 COMPOSITE ....................................................................................... 36 DECORATOR ...................................................................................... 41 FACADE .............................................................................................. 47 FACTORY METHOD ........................................................................... 51 FLYWEIGHT ........................................................................................ 56 INTERPRETER ................................................................................... 60 ITERATOR .......................................................................................... 63 MEDIATOR .......................................................................................... 67 MEMENTO .......................................................................................... 72 NULL OBJECT .................................................................................... 75 OBJECT POOL ................................................................................... 80 OBSERVER ......................................................................................... 84 PRIVATE CLASS DATA ..................................................................... 88 PROTOTYPE ....................................................................................... 90 PROXY ................................................................................................ 94 SINGLETON ........................................................................................ 97 STATE ............................................................................................... 101 STRATEGY ....................................................................................... 105 TEMPLATE METHOD ....................................................................... 109 VISITOR ............................................................................................ 113 ABOUT THE AUTHOR ..................................................................... 119

Índice | 5

Descripción general En la ingeniería de software, un patrón de diseño es una solución repetible en general a un problema frecuente en el diseño de software. Un patrón de diseño no es un diseño acabado que puede transformarse directamente en el código. Es una descripción o una plantilla para saber cómo solucionar un problema que puede ser utilizado en muchas situaciones diferentes. Los patrones de diseño pueden acelerar el proceso de desarrollo proporcionando Probado, demostrado paradigmas de desarrollo. Diseño de software eficaz requiere examinar cuestiones que pueden no ser visibles hasta más tarde en la aplicación. Reutilización de patrones de diseño ayuda a prevenir problemas sutiles que pueden causar grandes problemas y mejora la legibilidad del código para programadores y arquitectos están familiarizados con los patrones. A menudo, la gente sólo entender cómo aplicar ciertas técnicas de diseño de software para determinados problemas. Estas técnicas son difíciles de aplicar a una amplia gama de problemas. Los patrones de diseño ofrecen soluciones generales, documentado en un formato que no requiera específicos vinculados a un problema. Además, los patrones permiten a los desarrolladores comunicarse utilizando conocidas-, bien entendido nombres para las interacciones del software. Patrones de diseño comunes puede ser mejorado con el transcurso del tiempo, haciéndolos más robustos que ad- hoc de diseños.

6|

Patrones de creación. Este los patrones de diseño son todos acerca de la creación de instancias de clases. Este patrón puede ser dividido en patrones de creación de clase y objeto-patrones de creación. Mientras la clase-patrones de creación usar herencia eficazmente en el proceso de creación de instancias, objeto-patrones de creación utiliza la delegación efectiva para conseguir el trabajo hecho.

10 Abstract Factory. Crea una instancia de varias familias de clases Builder 24 Separa la construcción de objetos a partir de su representación. Método de fábrica 51 Crea una instancia de varias clases derivadas El grupo de objetos 80 Evitar el alto costo de adquisición y liberación de recursos por el reciclaje de objetos que ya no están en uso Prototipo 90 Un ejemplo totalmente inicializado para ser copiado o clonado 97 Singleton Una clase de la que sólo puede existir una instancia única

Overview | 7

Patrones estructurales Este los patrones de diseño son todos acerca de la composición de clase y objeto. Clase estructural-patrones de creación, utilizar la herencia para componer las interfaces. Objeto-patrones estructurales definir modos de componer objetos para obtener nuevas funcionalidades.

Adaptador 1 4 Coincidencia de diferentes clases, interfaces Puente 18 Separa la interfaz de un objeto desde su aplicación 36 compuestos Una estructura de árbol de objetos simples y compuestos Decorador 41 Agregar responsabilidades a objetos de forma dinámica Fachada 47 Una sola clase que representa un subsistema completo 56 mazarota Una instancia de grano fino utilizado para un intercambio eficiente Datos de clase privada 88 Restringe el descriptor de acceso/mutar acceso 94 Proxy Un objeto que representa otro objeto

8 | Overview

Patrones de comportamiento. Este los patrones de diseño son todos acerca de la clase de objetos de comunicación. Los patrones de comportamiento son aquellos patrones que son más específicamente relacionadas con la comunicación entre objetos. Cadena de responsabilidad 28 Una manera de pasar una solicitud entre una cadena de objetos Mando 32 Encapsular una petición de mandato como un objeto 60 intérprete Una forma de incluir elementos del lenguaje en un programa Iterador 63 Acceso secuencial de los elementos de una colección Mediador 67 Define la comunicación simplificada entre clases Memento 72 Capturar y restaurar el estado interno de un objeto. Objeto Null 75 Diseñado para actuar como un valor predeterminado de un objeto Observador 84 Una forma de notificar a muchas clases de cambio Estado 101 Modificar el comportamiento de un objeto cuando su estado cambia Estrategia 105 Encapsula un algoritmo dentro de una clase Método plantilla 109 Aplazar los pasos exactos de un algoritmo para una subclase 113 visitantes Define una nueva operación para una clase sin cambiar

Overview | 9

Abstract Factory. La intención • Proporcionar una interfaz para crear familias de objetos relacionados o dependientes sin especificar sus clases concretas. • Una jerarquía que encapsula: muchas posibles "plataformas", y la construcción de una suite de "productos". • El nuevo operador considerados dañinos.

Problema Si una aplicación es para ser portátil, necesita encapsular las dependencias de la plataforma. Estas "plataformas" podrían incluir: sistema de ventanas, sistema operativo, base de datos, etc. demasiado a menudo, esta encapsulación no está diseñado de antemano, y montones de #ifdef instrucciones case con opciones para todas las plataformas compatibles actualmente comienzan a procrear como conejos en todo el código.

Discusión Proporcionan un nivel de direccionamiento indirecto que abstrae la creación de familias de objetos relacionados o dependientes directamente sin especificar sus clases concretas. La "fábrica" objeto tiene la responsabilidad de proporcionar los servicios de creación de plataformas para toda la familia. Los clientes nunca crear objetos platform directamente, piden a la fábrica para hacerlo por ellos. Este mecanismo permite que el intercambio de familias de producto fácil porque la clase específica de la fábrica objeto aparece sólo una vez en la aplicación - donde es instanciado. La aplicación puede sustituir al por mayor a toda la familia de productos simplemente creando instancias de una instancia concreta diferentes de la fábrica abstracta. Porque el servicio prestado por el objeto de fábrica es tan generalizado, habitualmente se implementa como un singleton.

10 | Abstract Factory

Estructura La Fábrica Abstracta define un método de fábrica por producto. Cada método de fábrica encapsula el operador new y el hormigón, específica de la plataforma, las clases de productos. Cada "Plataforma" a continuación se modela con una clase derivada de fábrica.

Ejemplo El propósito de la fábrica abstracta es proporcionar una interfaz para crear familias de objetos relacionados, sin especificar las clases concretas. Este patrón se encuentra en la lámina de metal estampado el equipo utilizado en la fabricación de automóviles japoneses. El equipo de sellado es una Fábrica Abstracta que crea auto partes del cuerpo. La misma maquinaria se utiliza para marcar las puertas de derecha, izquierda, derecha puertas guardabarros delanteros, guardabarros delantero izquierdo, carcasas, etc. para diferentes modelos de coches. Mediante rodillos para cambiar la matricería, las clases concretas producidas por la maquinaria pueden cambiarse dentro de tres minutos.

Abstract Factory | 11

Lista de verificación  Decidir si la "independencia" de la plataforma y la creación de servicios son la fuente del dolor.  Trazar una matriz de "plataformas" versus "productos".  Definir una interfaz de fábrica que consta de un método de fábrica por producto.  Definir una clase derivada de fábrica para cada plataforma que encapsula todas las referencias al nuevo operador.  El cliente debe retirar todas las referencias al nuevo, y utilizar los métodos de fábrica para crear los objetos de producto.

Reglas del pulgar Patrones de creación a veces son competidores: hay casos cuando cualquiera de los prototipos o Fábrica Abstracta podría utilizarse provechosamente. Otras veces son complementarias: Abstract Factory puede almacenar un conjunto de prototipos para clonar y devolver el producto generador de objetos, puede utilizar uno de los otros modelos para aplicar lo que

12 | Abstract Factory

Los componentes se construyen. Fábrica Abstracta, constructor y prototipo puede utilizar Singleton en su aplicación. Fábrica Abstracta, constructor y prototipo definir un objeto de fábrica que es el responsable de conocer y crear la clase de objetos product, y hacen de él un parámetro del sistema. Abstract Factory tiene el objeto de fábrica producir objetos de varias clases. Builder tiene el objeto de fábrica construyendo un producto complejo de forma incremental mediante un protocolo complejo correspondientemente. Prototipo tiene el objeto de fábrica (aka prototipo) crear un producto copiando un objeto prototipo. Clases Abstract Factory suelen realizarse con métodos de fábrica, pero también se pueden aplicar utilizando Prototipo. Fábrica Abstracta puede ser usado como una alternativa a la fachada para ocultar las clases específicas de la plataforma. Builder se centra en construir un objeto complejo paso a paso. Abstract Factory destaca una familia de objetos product (simple o complejo). Builder devuelve el producto como un paso final, pero en cuanto a la Fábrica Abstracta, el producto se devuelve inmediatamente. A menudo, los diseños comiencen utilizando el método Factory (menos complicada, más personalizable, proliferan las subclases) y evolucionar hacia la Fábrica Abstracta, prototipos o Builder (más flexible, más complejo) como el diseñador descubre dónde se requiere más flexibilidad.

Abstract Factory | 13

Adaptador La intención  Convertir el interfaz de una clase en otra interfaz clientes esperan. Las clases de

adaptador permite trabajar juntos que no podría de otro modo debido a la incompatibilidad de las interfaces.  Envuelva una clase existente con una nueva interfaz.  Impedancia coincide con un antiguo componente a un nuevo sistema

Problema Un "off the shelf" el componente ofrece funcionalidad convincente que le gustaría volver a usar, pero su "visión del mundo" no es compatible con la filosofía y la arquitectura del sistema está siendo actualmente desarrollado.

Discusión Reutilizar siempre ha sido doloroso y difícil. Uno de los motivos ha sido la tribulación de diseñar algo nuevo, mientras que la reutilización de algo viejo. Siempre hay algo no anda bien entre el antiguo y el nuevo. Puede ser de las dimensiones físicas o desalineación. Puede ser temporización o sincronización. Puede ser lamentable suposiciones o estándares competitivos. Es como el problema de la inserción de un nuevo enchufe de tres clavijas en una vieja pared de dos clavijas - adaptador o intermediario es necesaria.

14 | Adapter

Adaptador es acerca de la creación de un intermediario abstracción que traduce, o mapas, el componente antiguo al nuevo sistema. Los clientes llamar a métodos en el objeto adaptador que redirecciona en llamadas a los componentes heredados. Esta estrategia puede aplicarse ya sea con la herencia o con agregación. El adaptador funciona como un contenedor o modificador de una clase existente. Proporciona una vista diferente o traducidos de esa clase.

Estructura A continuación, un legado del componente rectángulo método display espera recibir "x, y, w, h" parámetros. Pero el cliente quiere pasar "x y superior izquierdo" y "derecho inferior x e y". Esta incongruencia puede conciliarse añadiendo un nivel adicional de direccionamiento indirecto, es decir, un objeto de adaptador.

El adaptador también podría considerarse como un "contenedor".

Adapter | 15

Ejemplo El patrón Adapter permite incompatibles clases para trabajar juntos por la conversión de la interfaz de una clase en una interfaz esperada por los clientes. Llaves de tubo proporcionan un ejemplo del adaptador. Un socket atribuye a un trinquete, siempre que el tamaño de la unidad es la misma. Tamaños de unidad típica en los Estados Unidos son de 1/2" y 1/4". Obviamente, una carraca de 1/2" no caben en una hembra de 1/4" a menos que se usa un adaptador. Una de 1/2" a 1/4" adaptador tiene una conexión hembra de 1/2" para montar en la carraca de 1/2" y una conexión macho de 1/4" para montar en la toma de 1/4".

16 | Adapter

Lista de verificación 1. Identificar los actores: el componente(s) que desea ser alojados (es decir, el cliente) y el componente que necesita para adaptarse (es decir, el adaptador). 2. Identificar la interfaz que el cliente requiere. 3. Diseño de una clase "contenedor" que puede "Impedancia" coinciden con el adaptador para el cliente. 4. El adaptador/clase contenedora" "tiene una instancia de la clase de adaptador. 5. El adaptador/wrapper clase "mapas" en la interfaz del cliente para la interfaz del adaptador. 6. El cliente usa (está acoplado a la nueva interfaz)

Reglas del pulgar Adaptador hace las cosas funcionan después están diseñados; Puente les hace trabajar antes de que sean. Bridge está diseñado desde el principio para dejar que la abstracción y la ejecución varían de forma independiente. Se monta el adaptador para hacer clases independientes trabajan juntos. Adaptador proporciona una interfaz diferente a su objeto. Proxy ofrece la misma interfaz. Decorador proporciona una interfaz mejorada. Adaptador está destinada a cambiar la interfaz de un objeto existente. Decorador aumenta otro objeto sin cambiar su interfaz. Decorador es lo más transparente para la aplicación de un adaptador. Por lo tanto, decorador admite composición recursiva, lo cual no es posible con adaptadores de puro. Fachada define una nueva interfaz, mientras que el adaptador se reutiliza una interfaz antigua. Recuerde que el adaptador hace dos interfaces existentes de trabajar juntos, en lugar de definir una completamente nueva.

Adapter | 17

Puente La intención  Desvincular una abstracción de su implementación, de manera que los dos pueden

variar de forma independiente.  Publicar interfaz en una jerarquía de herencia, y enterrar la aplicación en

su propia jerarquía de herencia.  Más allá de la encapsulación, para aislamiento

Problema "Endurecimiento de las arterias" de software se ha producido mediante sub calificó de una clase base abstracta para proporcionar implementaciones alternativas. Esto bloquea en el enlace en tiempo de compilación entre interfaz e implementación. La abstracción y la aplicación no puede ser extendida de manera independiente o integrado.

Motivación Considerar el dominio de "hilo" de programación.

Hay dos tipos de hilo a planificadores, y dos tipos de sistemas operativos o "plataformas". Dado este enfoque a la especialización, debemos definir una clase para cada permutación de estas dos dimensiones. Si añadimos una nueva plataforma (digo ... Java Virtual Machine), ¿cuál sería nuestra jerarquía parecerse?

18 | Bridge

¿Lo que, si teníamos tres tipos de planificadores de rosca, y cuatro tipos de plataformas? ¿Lo que, si teníamos cinco tipos de hilo a planificadores, y diez tipos de plataformas? El número de clases que habría que definir es el producto del número de planes de programación y el número de plataformas. El patrón de diseño de puente propone esta refactorización exponencialmente explosivo jerarquía de herencia en dos jerarquías ortogonal - uno para abstracciones, independiente de la plataforma y el otro para la plataforma- dependientes implementaciones.

Discusión Se descomponen los componentes de la interfaz y la implementación dentro de las jerarquías de clases ortogonales. La clase de interfaz contiene un puntero a la clase de implementación abstracta. Este puntero se inicia con una instancia de la clase de aplicación concreta, pero toda la interacción posterior desde la interfaz Bridge | 19

Clase a la clase de implementación está limitada a la abstracción se mantienen en la implementación de la clase base. El cliente interactúa con la clase de interfaz, y a su vez "delegados" todas las solicitudes a la clase de implementación. La interfaz de objeto es el "handle" conocidos y utilizados por el cliente; mientras que el objeto de implementación, o "cuerpo", se encapsula de forma segura para garantizar que pueda seguir evolucionando, o ser totalmente sustituido (o compartido en tiempo de ejecución. Utilice el puente patrón cuando: • Desea el enlace en tiempo de ejecución de la aplicación, • Usted tiene una proliferación de clases derivadas de una interfaz acoplada y

numerosas implementaciones, • Desea compartir una aplicación entre varios objetos, • Usted necesidad de asignar jerarquías de clase ortogonales. Las

consecuencias incluyen: • Desacoplamiento de la interfaz del objeto, • Extensibilidad mejorada (puede extender (subclase), la abstracción y la

implementación de jerarquías de forma independiente), • Ocultar detalles de los clientes.

Puente es un sinónimo de la "ASA/cuerpo" idioma. Este es un mecanismo de diseño que encapsula una implementación clase dentro de una clase de interfaz. El primero es el cuerpo, y el último es el mango. La empuñadura es visto por el usuario como la clase real, pero el trabajo está hecho en el cuerpo. "El asa/cuerpo idioma clase puede usarse para descomponer una compleja abstracción en clases más pequeñas y manejables. El idioma puede reflejar el hecho de compartir un recurso único por varias clases que controlan el acceso a él (por ejemplo, el conteo de referencias)".

20 | Bridge

Estructura El cliente no quiere tratar con detalle dependiente de la plataforma. El Puente patrón encapsula esta complejidad detrás de una abstracción "contenedor". Puente destaca identificar y separar la "interfaz" de la abstracción de la "aplicación" de la abstracción.

Ejemplo El patrón Bridge desacopla una abstracción de su implementación, de modo que los dos pueden variar de forma independiente. Un hogar, interruptor de control de luces, ventiladores de techo, etc. es un ejemplo del puente. El propósito del interruptor para encender un dispositivo está encendido o apagado. El interruptor puede ser implementado como una cadena para tirar, simple con dos interruptores de posición, o una variedad de Interruptores de atenuador.

Bridge | 21

Lista de verificación 1. Decidir si dos dimensiones ortogonales existen en el dominio. Estos conceptos independientes podrían ser: abstracción/plataforma, o dominio/infraestructura o front-end/back-end, o interfaz/aplicación. 2. Diseñar la separación de preocupaciones: ¿qué es lo que el cliente quiere y qué hacen las plataformas proporcionan. 3. Diseñar una interfaz orientada a la plataforma que es mínima, necesaria y suficiente. Su objetivo es disociar la abstracción de la plataforma. 4. Definir una clase derivada de esa interfaz para cada plataforma. 5. Crear la clase base de abstracción que "plataforma" tiene un objeto y delegados de la plataforma funcionalidades orientadas a ella. 6. Definir las especializaciones de la clase de abstracción si lo desea.

Reglas del pulgar Adaptador hace las cosas funcionan después están diseñados; Puente les hace trabajar antes de que sean.

22 | Bridge

Bridge está diseñado desde el principio para dejar que la abstracción y la ejecución varían de forma independiente. Se monta el adaptador para hacer clases independientes trabajan juntos. Estado, Estrategia, Puente (y en cierta medida el adaptador) tienen estructuras similares de solución. Todos ellos comparten algunos elementos de la "ASA/cuerpo" idioma. Difieren en su intención, es decir, resuelven problemas diferentes. La estructura del Estado y el puente son idénticas (excepto que admite el puente sobre las jerarquías de clases, mientras que el Estado sólo permite uno). Los dos modelos utilizan la misma estructura para solucionar diferentes problemas: Estado permite un comportamiento del objeto para cambiar junto con su estado, mientras que el puente es la intención de desvincular una abstracción de su implementación, de manera que los dos pueden variar de forma independiente. Si las clases de interfaz delegar la creación de su aplicación (en lugar de crear clases/acoplamiento directamente), entonces el diseño normalmente usa el patrón Abstract Factory para crear los objetos de aplicación.

Bridge | 23

Builder La intención  Separar la construcción de un objeto complejo de su representación, de manera que el

mismo proceso de construcción puede crear diferentes representaciones.  Analizar una compleja representación, crear uno de varios objetivos.

Problema Una aplicación que necesita para crear los elementos de un complejo de agregados. La especificación para el agregado existe en el almacenamiento secundario y una de las muchas representaciones necesita ser construido en el almacenamiento primario.

Discusión Separar el algoritmo de interpretación (es decir, lectura y análisis) un mecanismo de persistencia almacenado (por ej. Archivos RTF) desde el algoritmo para construir y que representa uno de los muchos productos de destino (p. ej. ASCII, TeX, widget de texto). El foco o la distinción es en la creación de complejos agregados. El "director" invoca "constructor" servicios como interpreta el formato externo. El "constructor" crea la parte del complejo objeto cada vez que se llama y mantiene todos los estados intermedios. Cuando el producto es terminado, el cliente recupera el resultado del "constructor". Ofrece un mayor control sobre el proceso de construcción. A diferencia de los patrones de creación que construir productos en un solo disparo, el patrón Builder construye el producto paso a paso bajo el control del "director".

Estructura El lector encapsula el análisis de la entrada común. La jerarquía Builder hace posible la creación polimorfa de muchas representaciones peculiares o metas.

24 | Builder

Ejemplo El patrón generador separa la construcción de un objeto complejo de su representación, de manera que el mismo proceso de construcción puede crear diferentes representaciones. Este patrón es utilizado por los restaurantes de comida rápida para construir las comidas de los niños. Las comidas de los niños suelen constar de un tema principal, un tema lateral, una bebida y un juguete (por ejemplo, hamburguesas, patatas fritas, coque y dinosaurios de juguete). Tenga en cuenta que puede haber variaciones en el contenido de la comida para niños, pero el proceso de construcción es el mismo. Si un cliente pide una hamburguesa, hamburguesa con queso o pollo, el proceso es el mismo. El empleado en el mostrador dirige la tripulación para armar un tema principal, elemento lateral y juguete. Estos elementos se colocan en una bolsa. La bebida se coloca en un vaso y permanece fuera de la bolsa. Este mismo proceso se utiliza en restaurantes que compiten.

Builder | 25

Lista de verificación 1. Decidir si una entrada común y muchas representaciones posibles (o resultados) es el problema en la mano. 2. Encapsular el análisis de la entrada común en una clase de lector. 3. Diseñar un protocolo estándar para la creación de todas las representaciones de salida posible. Capturar los pasos de este protocolo en una interface Builder. 4. Definir un constructor de la clase derivada para cada destino de representación. 5. El cliente crea un objeto lector y generador de un objeto, y se registra el último con el primero. 6. El cliente pide al lector para "construir". 7. El cliente pide al generador para devolver el resultado.

26 | Builder

Reglas del pulgar A veces son complementarios: patrones de creación Builder puede utilizar uno de los otros patrones para implementar los componentes que se construyen. Fábrica Abstracta, constructor y prototipo puede utilizar Singleton en sus implementaciones. Builder se centra en construir un objeto complejo paso a paso. Abstract Factory destaca una familia de objetos product (simple o complejo). Builder devuelve el producto como un paso final, pero en cuanto a la Fábrica Abstracta, el producto se devuelve inmediatamente. Builder construye a menudo un compuesto. A menudo, los diseños comiencen utilizando el método Factory (menos complicada, más personalizable, proliferan las subclases) y evolucionar hacia la Fábrica Abstracta, prototipos o Builder (más flexible, más complejo) como el diseñador descubre dónde se requiere más flexibilidad.

Builder | 27

Cadena de responsabilidad La intención  Evitar el acoplamiento al remitente de una solicitud a su receptor por dar más de un

objeto una oportunidad para atender la solicitud. La cadena recibir objetos y pasa la solicitud a lo largo de la cadena hasta un objeto lo maneja.  Lanzamiento y solicitudes de permiso con una sola canalización de procesamiento

que contiene muchos posibles controladores.  Orientado a Objetos lista vinculada con un desplazamiento recursivo.

Problema No es potencialmente un número variable de "handler" o "elementos de procesamiento" o "nodo" los objetos, y un flujo de peticiones que debe gestionar. Necesidad de procesar eficientemente las solicitudes sin cableado handler y relaciones de precedencia, o solicitud de asignaciones de controlador.

Discusión Encapsular el procesamiento de elementos dentro de una abstracción "pipeline"; y que los clientes "lanzamiento" y dejar sus peticiones en la entrada de la canalización.

28 | Chain of Responsibility

Las cadenas de patrones la recepción de objetos juntos y luego pasa cualquier solicitud mensajes de objeto a objeto hasta que alcanza un objeto capaz de procesar el mensaje. El número y el tipo de los objetos del controlador se desconoce a priori, pueden ser configurados dinámicamente. El mecanismo utiliza encadenamiento composición recursiva para permitir un número ilimitado de controladores a vincularse. Cadena de responsabilidad simplifica las interconexiones de objetos. En lugar de los emisores y receptores, manteniendo las referencias a todos los posibles receptores, cada emisor mantiene una sola referencia a la cabeza de la cadena, y cada receptor mantiene una sola referencia a su sucesor inmediato en la cadena. Asegúrese de que existe una "red de seguridad" para "capturar" cualquier petición que vaya no controlada. No utilice la cadena de responsabilidad cuando cada solicitud sólo es manejado por un controlador, o bien, cuando el cliente sabe qué objeto de servicio debe atender la solicitud.

Estructura Las clases derivadas sabe cómo satisfacer las peticiones del cliente. Si el objeto "actual" no está disponible o suficiente, delegados de la clase base, que delega en el objeto "siguiente", y el círculo de la vida continúa.

Chain of Responsibility | 29

Múltiples controladores podrían contribuir a la tramitación de cada solicitud. La solicitud puede ser aprobada por toda la longitud de la cadena, con el último eslabón, teniendo cuidado de no delegar en un valor "null" siguiente.

Ejemplo La cadena de responsabilidad patrón evita el acoplamiento del remitente de una solicitud para el receptor, dando más de un objeto una oportunidad para atender la solicitud. ATM utilice la cadena de responsabilidad en dinero dando mecanismo.

30 | Chain of Responsibility

Lista de verificación 1. La clase base mantiene un puntero "siguiente". 2. Cada clase derivada implementa su contribución para la manipulación de la solicitud. 3. Si la petición debe ser "transmitido", entonces la clase derivada de "llamadas" a la clase base, que delega en el puntero "siguiente". 4. El cliente (o un tercero) crea y vincula la cadena (que puede incluir un enlace del último nodo hasta el nodo raíz). 5. El cliente "lanza y hojas" cada petición con la raíz de la cadena. 6. Delegación recursiva produce la ilusión de la magia.

Reglas del pulgar Cadena de responsabilidad, mando, mediador y observador, abordar el tema de cómo puede desacoplar los emisores y receptores, pero con diferentes compensaciones recíprocas. Cadena de responsabilidad pasa una solicitud del remitente a lo largo de una cadena de potenciales receptores. Cadena de responsabilidad, puede utilizar el mando para representar las solicitudes como objetos. Cadena de responsabilidad se aplican a menudo en conjunción con composite. Allí, un componente primario puede actuar como su sucesor.

Chain of Responsibility | 31

Mando La intención  Encapsular una petición como un objeto, permitiéndole así parametrizar clientes con

diferentes solicitudes, la cola o las solicitudes de registro y apoyo deshacer operaciones.  Promover "la invocación de un método en un objeto" al estado de objeto completo  Una retro llamada orientada a objetos

Problema Es necesario emitir peticiones a objetos sin saber nada acerca de la operación que se solicite o el receptor de la solicitud.

Discusión Comando separa el objeto que invoca la operación del uno que sabe cómo realizar. Para lograr esta separación, el diseñador crea una clase base abstracta que asigna un receptor (un objeto) con una acción (un puntero a una función miembro). La clase base contiene un método execute que simplemente llama a la acción en el receptor. Todos los clientes de objetos Command tratar cada objeto como una "caja negra" por el sólo hecho de invocar el método Execute del objeto virtual cada vez que el cliente requiere que el objeto del "servicio". Una clase de comando posee algún subconjunto de los siguientes: un objeto, un método que se aplica al objeto, y los argumentos que se pasan al método aplicado. El comando "Ejecutar" método provoca que las piezas se unen. Las secuencias de comandos pueden montarse en los objetos compuestos (o macro) comandos.

Estructura El cliente que crea un comando no es el mismo cliente que ejecuta. Esta separación proporciona flexibilidad en el calendario y la secuencia de comandos. Materializando los comandos como objetos significa

32 | Command

Se pueden transmitir, escenificada, compartido, cargado en una tabla y, de lo contrario el instrumentado o manipularse como cualquier otro objeto.

Objetos de comando puede ser pensado como "tokens" que son creados por un cliente que sabe lo que hay que hacer, y pasa a otro cliente que tiene los recursos para hacerlo.

Ejemplo El patrón de comando permite peticiones para ser encapsulado como objetos, permitiendo a los clientes ser parametrizada con diferentes solicitudes. La "comprobación" en un diner es un ejemplo de un patrón de comando. El camarero o camarera toma una orden o mandato de un cliente, y encapsula ese orden por escrito en el cheque. El pedido ya está en la cola para un corto fin de Cook. Tenga en cuenta que la pastilla de "controles" utilizado por cada camarero no es dependiente en el menú, y por lo tanto no puede admitir comandos para cocinar muchos elementos diferentes.

Command | 33

Lista de verificación 1. Definir una interfaz de comandos con una firma de método como ejecutar. 2. Crear una o más clases que encapsulan derivado algún subconjunto de lo siguiente: un "receptor", el método de objeto para invocar, los argumentos que se pasan. 3. Instanciar un objeto de comando para cada solicitud de ejecución diferida. 4. Pase el objeto Command del creador (aka remitente) para el invocador (aka receptor). 5. El invocador decide cuándo ejecutar.

Reglas del pulgar Cadena de responsabilidad, mando, mediador y observador, abordar el tema de cómo puede desacoplar los emisores y receptores, pero con diferentes compensaciones recíprocas. Comando normalmente especifica una conexión emisor-receptor con una subclase. Cadena de responsabilidad, puede utilizar el mando para representar las solicitudes como objetos. Mando y Memento actúan como magic tokens para ser circular y se invoca más adelante. En el comando, el símbolo representa una solicitud; en Memento, representa el estado interno de un objeto en un determinado

34 | Command

Tiempo. El polimorfismo es importante comando, pero no recuerdo porque su interfaz es tan estrecha que un recuerdo sólo puede ser pasado como un valor. Puede utilizar el comando Memento para mantener el estado requerido para una operación de deshacer. Los comandos de macro pueden implementarse con composite. Un comando que debe ser copiado antes de ser colocado en una lista de historial actúa como un prototipo. Dos aspectos importantes del patrón de comando: interfaz de separación (el invocador está aislado del receptor), el tiempo de separación (almacena un listo para ir Procesando solicitud que se declaró más tarde).

Command | 35

Composite La intención  Componer objetos en estructuras de árbol para representar jerarquías parte

entera. Composite permite a los clientes tratar los objetos individuales y composiciones de objetos uniformemente.  Composición recursiva  "Los directorios contienen entradas, cada una de las cuales podría ser un directorio".  1-a-muchos "a" hasta la "es una jerarquía"

Problema Las necesidades de la aplicación para manipular un conjunto jerárquico de "primitivo" y "composite" objetos. El procesamiento de un objeto primitivo se maneja de una manera, y el procesamiento de un objeto compuesto se maneja de forma diferente. Tener consulta el "tipo" de cada objeto antes de intentar procesar no es deseable.

Discusión Definir una clase base abstracta (Componente) que especifica el comportamiento que debe ejercerse de manera uniforme en todos los primitivos y los objetos compuestos. Crear una subclase de la primitiva y clases compuestas fuera de la clase Component. Cada objeto compuesto "parejas" por sí solo a los tipos abstractos como componente gestiona sus "hijos". Usar este patrón cuando tenga "compuestos que contienen componentes, cada uno de los cuales podría ser un composite". Métodos de gestión del niño (Agregar hijo, Quitar hijo) normalmente debería estar definido en la clase compuesta. Lamentablemente, el deseo de tratar primitivas y Composites uniformemente requiere que estos métodos se moverán a la clase de componente abstracto. Ver las opiniones en la sección de abajo para una discusión de la seguridad frente a los problemas de la transparencia.

36 | Composite

Estructura Los compuestos que contienen componentes, cada uno de los cuales podría ser un compuesto.

Los menús que contienen elementos de menú, cada uno de los cuales podría ser un menú. Fila-columna gestores de diseño de GUI que contienen widgets, cada uno de los cuales podría ser una GUI de fila-columna gestor de diseño. Los directorios que contienen archivos, cada uno de los cuales podría ser un directorio.

Ejemplo El compuesto se compone de objetos en estructuras de árbol y permite a los clientes tratar los objetos individuales y composiciones de manera uniforme. Aunque el ejemplo es abstracto, expresiones aritméticas son compuestos. Una expresión aritmética consta de un operando, un operador (+ - * /), y el otro operando. El operando puede ser un número o una expresión aritmética. Por lo tanto, 2 + 3 y 2 + 3) + (4 * 6) son dos de las expresiones válidas.

Composite | 37

Lista de verificación 1. Asegúrese de que su problema es sobre todo que representan la "parte de" las relaciones jerárquicas. 2. Considerar el heurístico, "recipientes que contengan contenedores, cada uno de los cuales podría ser un contenedor". Por ejemplo, "los ensamblados que contienen componentes, cada uno de los cuales podría ser un montaje." Divida su dominio de los conceptos en las clases de contenedor, y contenía las clases. 3. Crear un "mínimo común denominador" interfaz que hace que sus contenedores y contenedores intercambiables. Debe especificar el comportamiento que debe ejercerse de manera uniforme a través de todos los contenidos y objetos contenedor. 4. Todo el contenedor y el contenido de las clases declarar una relación "es un" a la interfaz. 5. Todas las clases de contenedor declarar un uno-a-muchos "tiene una relación" a la interfaz. 6. Las clases de contenedor aprovechar el polimorfismo para delegar a sus objetos contenidos. 7. Métodos de gestión del niño (Agregar hijo, Quitar hijo) normalmente debería estar definido en la clase compuesta. Lamentablemente, el deseo de tratar la hoja y uniformemente los objetos compuestos pueden requerir que estos métodos sean promovidos a la clase de componente abstracto. Ver la pista de 4 para una discusión de estos "seguridad" versus "transparencia" compensaciones.

38 | Composite

Reglas del pulgar Y Decorador compuesto tienen una estructura similar de diagramas, reflejando el hecho de que ambos se basan en la composición recursiva para organizar un abierto número de objetos. Composite puede recorrerse con el iterador. Visitante puede aplicar una operación sobre un compuesto. Composite podría usar cadena de responsabilidad para permitir acceso a los componentes de las propiedades globales a través de sus padres. También podría usar el decorador para omitir estas propiedades en partes de la composición. Podría utilizar observador para atar una estructura de objeto a otro Estado y dejar de cambiar un componente, su comportamiento como sus cambios de estado. Puede compuesto le permiten componer un mediador de los pedazos más pequeños a través de la composición recursiva. Decorador está diseñado para permitirle agregar responsabilidades a objetos sin sub clasificadores. Los compuestos no se concentran en el embellecimiento sino en la representación. Estos intentos son diferentes pero complementarias. Por consiguiente, Composite y decorador se utilizan a menudo en concierto. A menudo se combina con la mazarota para aplicar compuesto compartieron los nodos hoja.

Opiniones Toda la cuestión del patrón Composite es que el compuesto puede ser tratada de forma atomizada, justo como una hoja. Si desea proporcionar un iterador protocolo, bien, pero creo que está fuera de la trama en sí. En el corazón de este patrón es la capacidad de un cliente para realizar operaciones en un objeto sin necesidad de saber que hay muchos objetos en su interior. Ser capaz de tratar una colección heterogénea de objetos de forma atómica (o transparente) requiere que el "niño" se define la interfaz de gestión en la raíz de la jerarquía de clases de compuestos (la clase de componente abstracta). Sin embargo, esta elección cuesta su seguridad, porque los clientes pueden tratar de hacer cosas sin sentido como añadir y quitar objetos de objetos hoja. Por otro lado, si el "diseño de seguridad", el niño es declarado en la interfaz de administración de la clase compuesta, y usted Composite | 39

Transparencia porque pierden las hojas y Composites ahora tienen interfaces diferentes. Smalltalk implementaciones del patrón compuesto generalmente no tiene la interfaz para administrar los componentes de la interfaz de componente, pero en la interfaz compuesta. Las implementaciones de C++ tienden a ponerlo en la interfaz del componente. Este es un hecho sumamente interesante, y que a menudo me ponder. Yo puedo ofrecer teorías para explicar, pero nadie sabe por qué es cierto. Mis clases de componentes no saben que existen compuestos. No proporcionan ayuda para navegar en composites, ni ninguna ayuda para alterar el contenido de un compuesto. Esto es porque quisiera que la clase base (y todos sus derivados) para ser reutilizable en contextos que no requieran de Composites. Cuando se administra un puntero de clase base, si me lo absolutamente necesario para saber si es un compuesto, usaré la conversión dinámica para averiguarlo. En aquellos casos en los que la conversión dinámica es demasiado cara, utilizaré un visitante. Queja común: "Si me empuje la interfaz compuesta hacia la clase de compuesto, ¿cómo voy a enumerar ((i.e. traverse)) una estructura compleja?" Mi respuesta es que cuando tengo los comportamientos que se aplican a las jerarquías como el presentado en el patrón Composite, yo normalmente uso visitante, la enumeración no es un problema - el visitante sabe en cada caso, exactamente qué tipo de objeto con el que está tratando. El visitante no necesita cada objeto para proporcionar una interfaz de enumeración. Carta compuesta no le obligan a tratar todos los componentes como los composites. Simplemente le dice a poner todas las operaciones que desee para tratar de manera "uniforme" en la clase de componente. Si agregar, quitar y operaciones similares pueden, o no deben, ser tratados de manera uniforme, entonces no ponerlos en la clase base Component. Recuerde, por cierto, que cada uno de los patrones del diagrama de estructura no define el patrón; simplemente describe lo que en nuestra experiencia es una comprensión común del mismo. Sólo porque la estructura del compuesto diagrama muestra las operaciones de gestión de niño en la clase base Component no significa que todas las implementaciones del patrón deben hacer lo mismo.

40 | Composite

Decorador La intención • Fijar responsabilidades adicionales a un objeto dinámicamente. Decoradores ofrecen

una alternativa flexible para sub clasificadores para ampliar la funcionalidad. • Especificada por el cliente en el embellecimiento de un objeto central por un

ajuste de forma recursiva. • Envolver un regalo, ponerla en una caja, y envolver la caja.

Problema Desea agregar el comportamiento o el estado de los objetos individuales en tiempo de ejecución. La herencia no es viable porque es estático y se aplica a toda una clase.

Discusión Supongamos que usted está trabajando en un toolkit de interfaz de usuario y desea agregar bordes y barras de desplazamiento para Windows. Puede definir una jerarquía de herencia como

Decorator | 41

Pero el patrón Decorador sugiere darle al cliente la posibilidad de especificar cualquier combinación de "características" sea la deseada. Widget

Nueva BorderDecorator aWidget =( Nuevo VerticalScrollBarDecorator HorizontalScrollBarDecorator(( Nueva ventana ( 80, 24 )))); AWidget->draw();

Esta flexibilidad se puede lograr con el siguiente diseño

Otro ejemplo de cascada (o encadenamiento) características juntas para producir un objeto personalizado podría parecerse Stream

Nueva CompressingStream aStream =( Nuevo Stream(7ASCII New FileStream("archivo.dat" ))); aStream->putString( "Hello world");

La solución a esta clase de problemas implica que encapsula el objeto original dentro de una interfaz contenedora abstracta. Tanto el decorador de objetos y el objeto principal heredan de este interfaz abstracto. La interfaz utiliza la composición recursiva para permitir un número ilimitado de decorador "capas" para ser añadidos a cada núcleo objeto. Tenga en cuenta que este modelo permite responsabilidades que se agrega a un objeto, no métodos a un objeto de la interfaz. La interfaz presentada al cliente debe permanecer constante como capas sucesivas se especifican.

42 | Decorator

También tenga en cuenta que el núcleo de la identidad del objeto ha sido "escondido" dentro de un decorador objeto. Intentando acceder al objeto principal directamente, es ahora un problema.

Estructura El cliente siempre está interesado en CoreFunctionality.hacerlo(). El cliente puede o no estar interesado en OptionalOne.hacerlo() y OptionalTwo.hacerlo(). Cada una de estas clases siempre delegar en el decorador clase base, y que la clase siempre delegados de la figura "Encintado" objeto.

Ejemplo El decorador atribuye responsabilidades adicionales a un objeto dinámicamente. Los ornamentos que se agregan al pino o abeto son ejemplos de decoradores. Luces, Garland, bastones de caramelo, adornos de cristal, etc., pueden añadirse a un árbol para darle un aspecto festivo. Los adornos no cambien el árbol que es reconocible como un árbol de Navidad, independientemente de ornamentos utilizados. Como un ejemplo de funcionalidad adicional, la adición de luces permite "iluminar" un árbol de Navidad.

Decorator | 43

Aunque las pinturas pueden ser colgado en una pared con o sin marcos, marcos se añaden con frecuencia, y es la trama que se cuelga en la pared. Antes de colgar, las pinturas pueden ser enmarañada y enmarcado, con la pintura, alfombras, y el bastidor formando un único componente visual.

Lista de verificación 1. Asegurar el contexto es: un único núcleo (o no) al componente opcional, varios adornos opcional o contenedores, y una interfaz que es común a todos. 2. Crear un "mínimo común denominador" interfaz que hace que todas las clases son intercambiables. 3. Crear una clase base de segundo nivel (Decorador) para apoyar las clases contenedoras opcional. 44 | Decorator

4. La clase básica y clase Decorador heredan de la interfaz LCD. 5. El decorador clase declara una relación de composición para la interfaz LCD, este miembro de datos y se inicializa en su constructor. 6. La clase Decorador delegados al objeto de LCD. 7. Definir una clase derivada de decorador para cada Adorno opcional. 8. Las clases derivadas de decorador implementar su funcionalidad wrapper - y delegado para el decorador clase base. 9. El cliente configura el tipo y orden de Core y decorador de objetos.

Reglas del pulgar Adaptador proporciona una interfaz diferente a su objeto. Proxy ofrece la misma interfaz. Decorador proporciona una interfaz mejorada. Adaptador de interfaz de un objeto cambia, decorador aumenta las responsabilidades de un objeto. Decorador es lo más transparente para el cliente. Por lo tanto, decorador admite composición recursiva, lo cual no es posible con adaptadores de puro. Y Decorador compuesto tienen una estructura similar de diagramas, reflejando el hecho de que ambos se basan en la composición recursiva para organizar un abierto número de objetos. Un decorador puede verse como un degenerado compuestas con un solo componente. Sin embargo, un decorador agrega responsabilidades adicionales, es decir, no está pensado para la agregación de objetos. Decorador está diseñado para permitirle agregar responsabilidades a objetos sin sub clasificadores. El compuesto no se concentra en el embellecimiento sino en la representación. Estos intentos son diferentes pero complementarias. Por consiguiente, Composite y decorador se utilizan a menudo en concierto. Composite podría usar cadena de responsabilidad para permitir acceso a los componentes de las propiedades globales a través de sus padres. También podría usar el decorador para omitir estas propiedades en partes de la composición.

Decorator | 45

Decorador y Proxy tienen propósitos diferentes, pero estructuras similares. Ambos describen cómo proporcionar un nivel de direccionamiento indirecto a otro objeto, y las implementaciones mantener una referencia al objeto al que reenviar solicitudes. Decorador: permite cambiar la piel de un objeto. Estrategia permite cambiar las tripas.

46 | Decorator

Fachada La intención • Proporcionar una interfaz unificada para un conjunto de interfaces en un

subsistema. Fachada define una interfaz de alto nivel que hace que los subsistemas más fáciles de usar. • Envolver un subsistema complicada con una interfaz más sencilla.

Problema Un segmento de la comunidad del cliente necesita una interfaz simplificada para la funcionalidad general de un complejo subsistema.

Discusión Fachada explica que encapsula un complejo subsistema dentro de una sola interfaz objeto. Esto reduce la curva de aprendizaje necesaria para aprovechar con éxito el subsistema. También promueve la disociación del subsistema de su potencialmente muchos clientes. Por otro lado, si la fachada es el único punto de acceso para el subsistema, limitará las opciones y flexibilidad que los "usuarios avanzados" puede necesitar. El objeto debe ser una fachada simple promotor o facilitador. No debe convertirse en un todo conocimiento de Oracle o "dios" objeto.

Estructura Fachada toma "una adivinanza envuelta en un enigma envuelto en el misterio", y añaden un contenedor que doma el inescrutable y amorfa masa de software.

Facade | 47

Y SubsystemOne SubsystemThree no interactúa con los componentes internos de SubsystemTwo. Ellos utilizan la fachada SubsystemTwoWrapper (es decir, el mayor nivel de abstracción).

48 | Facade

Ejemplo La fachada define una interfaz unificada, nivel superior a un subsistema que facilita el uso. Los consumidores encuentran una fachada con el pedido de un catálogo. El consumidor llama a un número y habla con un representante de servicio al cliente. El representante del servicio de atención al cliente actúa como una fachada, proporcionando una interfaz para el departamento de cumplimiento de pedidos, el departamento de facturación, y el departamento de envíos.

Lista de verificación 1. Identificar una sencilla interfaz unificada para el subsistema o componente. 2. Diseño de la envoltura de una clase que encapsula el subsistema. 3. La fachada/wrapper capta la complejidad y colaboraciones del componente, y los delegados a los métodos apropiados. 4. El cliente utiliza (es) acoplada a la fachada solamente. 5. Considerar si la fachada adicional agregaría valor.

Facade | 49

Reglas del pulgar Fachada define una nueva interfaz, mientras que el adaptador utiliza una interfaz antigua. Recuerde que el adaptador hace dos interfaces existentes de trabajar juntos, en lugar de definir una completamente nueva. Mientras que el peso centrífugo se muestra cómo hacer que un montón de pequeños objetos, fachada nos muestra cómo hacer que unos solos objetos representan todo un subsistema. Es como mediador en la fachada que abstrae la funcionalidad de las clases existentes. Abstracts/mediador centraliza las comunicaciones entre colega objetos arbitrarios. Rutinariamente "agrega valor", y es conocido/referenciado por el colega de objetos. En contraste, la fachada define una interfaz simple para un subsistema, no agrega nueva funcionalidad, y no es conocido por el subsistema de clases. Fábrica Abstracta puede ser usado como una alternativa a la fachada para ocultar las clases específicas de la plataforma. Fachada objetos son a menudo Singletons porque sólo una fachada objeto es requerida. Adaptador y fachada son ambos contenedores; pero son distintos tipos de contenedores. La intención de la fachada es para producir una interfaz más simple, y la intención del adaptador es diseñar una interfaz existente. Mientras la fachada envolturas rutinariamente varios objetos y el adaptador se envuelve un único objeto; Fachada podría un único front-end y el adaptador de objeto complejo podía envolver varios objetos heredados.

50 | Facade

Método de fábrica La intención • Definir una interfaz para crear un objeto, pero que las subclases decidan qué clase

instanciar. Método de fábrica permite una clase aplazar la instanciación de subclases. • Definir un constructor "virtual". • El nuevo operador considerados dañinos.

Problema Necesita un marco para estandarizar el modelo arquitectónico para una variedad de aplicaciones, pero permitir aplicaciones individuales para definir sus propios objetos de dominio y prever su instanciación.

Discusión Método de fábrica es la creación de objetos como método de Plantilla es implementar un algoritmo. Una superclase especifica todos los estándares y comportamiento genérico (usando virtual puro "marcadores" para la creación de pasos), y luego la creación de delegados detalles para las subclases que son suministrados por el cliente. Método de fábrica hace un diseño más personalizable y sólo un poco más complicado. Otros patrones de diseño requieren nuevas clases, mientras que el método de fábrica sólo requiere una nueva operación. La gente a menudo utiliza método de fábrica como la manera estándar para crear objetos, pero no es necesario si: la clase que se instancian nunca cambia, o la instanciación se lleva a cabo en una operación que las subclases pueden alterar fácilmente (como una operación de inicialización). Método de fábrica es como Fábrica Abstracta, pero sin el énfasis en las familias. Métodos de fábrica son rutinariamente especificada por un marco arquitectónico, y luego ejecutado por el usuario del marco.

Factory Method | 51

Estructura La aplicación del método de fábrica discutidos en la banda de los cuatro (abajo) se superpone en gran parte con la de Fábrica Abstracta. Por esa razón, en la presentación de este capítulo se centra en el enfoque que se ha popularizado desde entonces.

Una definición de cada vez más popular método de fábrica es: un método estático de una clase que devuelve un objeto de esa clase". Pero a diferencia de un constructor, se devuelve el objeto real puede ser una instancia de una subclase. A diferencia de un constructor, un objeto existente puede ser reutilizado, en lugar de crear un nuevo objeto. A diferencia de un constructor, pueden tener diferentes métodos de fábrica y nombres más descriptivos (por ej. Color.make_float_color(RGB rojo, verde, azul de flotación flotación) y Color.make_color_HSB(float matiz, saturación, brillo de flotación flotación)

52 | Factory Method

El cliente es totalmente desvinculado de los detalles de implementación de clases derivadas. Creación polimorfa es ahora posible.

Ejemplo El método de fábrica define una interfaz para crear objetos, pero vamos a las subclases decidir qué clases para instanciar. Prensas de moldeo por inyección demuestran este patrón. Fabricantes de juguetes de plástico proceso de moldeo de plástico en polvo, e inyectar el plástico en los moldes de las formas deseadas. La clase de juguete (coche, figura de acción, etc.) está determinada por el molde.

Factory Method | 53

Lista de verificación 1. Si usted tiene una jerarquía de herencia que ejerce el polimorfismo, considere la adición de una creación polimorfa capacidad estática mediante la definición de un método de fábrica en la clase base. 2. Diseñar los argumentos para el método de fábrica. ¿Qué cualidades o características son necesarias y suficientes para determinar la correcta para crear instancias de la clase derivada? 3. Considerar el diseño de un conjunto de objetos "internos" que permitirá que los objetos que se reutilizan en lugar de crear desde cero. 4. Considere hacer todos los constructores privados o protegidos.

Reglas del pulgar Clases Abstract Factory suelen realizarse con métodos de fábrica, pero pueden implementarse a través de prototipo. Métodos de fábrica son generalmente llamados métodos dentro de la plantilla. Método de fábrica: creación a través de la herencia. Prototipo: creación a través de la delegación. A menudo, el diseño comience utilizando el método Factory (menos complicada, más personalizable, proliferan las subclases) y evolucionar hacia Resumen 54 | Factory Method

Fábrica, prototipos o Builder (más flexible, más complejo) como el diseñador descubre dónde se requiere más flexibilidad. Prototipo no requiere sub clasificadores, pero requiere una operación de inicialización. Método de fábrica requiere sub clasificadores, pero no requiere la inicialización. La ventaja de un método de fábrica es que puede volver a la misma instancia varias veces, o puede devolver una subclase en lugar de un objeto de ese tipo exacto. Algunos defensores del método de fábrica recomiendan que, como una cuestión de diseño del lenguaje (o en su defecto, como una cuestión de estilo) absolutamente todos los constructores deben ser privadas o protegidas. Es nadie negocio si una clase fabrica un nuevo objeto o recicla un antiguo. El nuevo operador considerados dañinos. Hay una diferencia entre solicitar un objeto y crear uno. El nuevo operador siempre crea un objeto y falla para encapsular la creación de objetos. Un método de fábrica exige que el encapsulamiento, y permite que un objeto sea solicitado sin acoplamiento inextricable para el acto de la creación.

Factory Method | 55

Pesos centrífugos La intención  Uso compartido para apoyar a un gran número de objetos de grano fino de

forma eficiente.  La GUI Motif estrategia de sustitución de peso pesado ligero widgets con gadgets.

Problema Diseñando objetos a los niveles más bajos del sistema "granularidad" proporciona una flexibilidad óptima, pero puede ser demasiado costoso en términos de rendimiento y uso de memoria.

Discusión El patrón de mazarota describe cómo compartir objetos para permitir su uso en multa granularities sin costo prohibitivo. Cada "contrapeso" objeto se divide en dos partes: el estado-dependiente (extrínseca) parte, y el estado independiente de parte (intrínseco). Se almacena el estado intrínseco (compartido) en el objeto de mazarota. Se almacena el estado extrínseco o tomografía por objetos de cliente, y se pasa a la mazarota sus operaciones cuando se invocan. Un ejemplo de este enfoque sería Motif widgets que han sido rediseñado como lightweight gadgets. Mientras que los widgets son lo suficientemente "inteligentes" para pararse sobre sus propios gadgets; existe en una relación dependiente con su gestor de diseño principal widget. Cada Layout Manager ofrece gestión de eventos dependientes del contexto, gestión inmobiliaria, servicios y recursos a sus gadgets, y mazarota cada gadget es responsable sólo del contexto independiente del estado y el comportamiento.

Estructura Contrapesos se almacenan en un repositorio de la fábrica. El cliente frena ella misma de crear contrapesos directamente, y les pide desde el

56 | Flyweight

Fábrica. Cada contrapeso no puede valerse por sí mismo. Los atributos que haría imposible compartir debe ser suministrado por el cliente cuando se realiza una solicitud de la mazarota. Si el contexto se presta a la "economía de escala" (es decir, el cliente puede fácilmente calcular o mirar los atributos necesarios), entonces el patrón de mazarota ofrece apalancamiento apropiado.

La Hormiga, Langosta Cucaracha , y las clases pueden ser liviano porque su estado específico de la instancia ha sido des encapsula, o externalizado, y deben ser suministrados por el cliente.

Flyweight | 57

Ejemplo La Mazarota compartir utiliza para apoyar a un gran número de objetos de forma eficiente. La red telefónica pública conmutada es un ejemplo de un contrapeso. Hay varios recursos como generadores de tono de marcado, sonando de generadores y receptores de dígitos que debe compartirse entre todos los suscriptores. Un suscriptor no tiene conocimiento de cuántos recursos están en la piscina cuando él o ella levanta el teléfono para realizar una llamada. Todo lo que importa a los suscriptores es que proporciona un tono de marcado, los dígitos son recibidos, y finaliza la llamada.

Lista de verificación 1. Asegúrese de que la sobrecarga de objetos es una cuestión que requiere atención, y el cliente de la clase sea capaz y esté dispuesto a absorber la responsabilidad realineación. 2. Divida la clase en el estado de destino: estado (intrínseco) compartibles y no compartibles extrínseca (estado). 3. No quitar el estado compartible desde los atributos de las clases, y agregarlo a la lista de argumentos de llamada de los métodos. 4. Crear una fábrica que puede almacenar y reutilizar las instancias de la clase. 5. El cliente debe utilizar la fábrica en lugar del nuevo operador solicitar objetos. 6. El cliente (o un tercero) debe buscar o calcular los estados no compartibles, y suministrar a ese Estado a métodos de clase.

58 | Flyweight

Reglas del pulgar Mientras que los pesos centrífugos se muestran cómo hacer que un montón de pequeños objetos, fachada nos muestra cómo hacer que unos solos objetos representan todo un subsistema. A menudo se combina con la mazarota para aplicar compuesto compartieron los nodos hoja. Los símbolos terminales dentro del intérprete de árbol de sintaxis abstracta pueden ser compartida con contrapeso. Mazarota Estado describe cuándo y cómo los objetos pueden ser compartidos.

Flyweight | 59

Intérprete La intención  Dado un lenguaje, define una representación de su gramática junto con un intérprete

que usa la representación para interpretar frases en el idioma.  Asignar un dominio a un idioma, el idioma de una gramática, y la gramática de

un diseño orientado a objetos jerárquicos.

Problema Una clase de problemas se produce repetidamente en un bien definido y bien entendido dominio. Si el dominio se caracterizó con un "idioma", entonces los problemas pueden solucionarse fácilmente con una interpretación "motor".

Discusión El patrón intérprete explica: definir un lenguaje de dominio (es decir, la caracterización de problemas) como un lenguaje simple gramática, representando reglas de dominio como idioma frases, e interpretar estas frases para resolver el problema. El modelo utiliza una clase para representar cada regla gramatical. Y desde gramáticas están generalmente en la estructura jerárquica, una jerarquía de herencia de clases de regla mapas agradablemente. Una clase base abstracta especifica el método interpretar. Cada subclase concreta implementa interpretar aceptando (como argumento) el estado actual de la lengua corriente, y la adición de su contribución al proceso de solución de problemas.

Estructura Intérprete sugiere modelado del dominio con una gramática recursiva. Cada regla de la gramática es un 'composite' (una regla que hace referencia a otras normas) o un terminal (un nodo hoja en una estructura de árbol). Intérprete se basa en la travesía recursiva del patrón Composite para interpretar la 'sentences' es solicitado a proceso.

60 | Interpreter

Ejemplo El intérprete define un patrón de representación gramatical de un idioma y un intérprete para interpretar la gramática. Los músicos son ejemplos de intérpretes. El tono de un sonido y su duración puede ser representado en notación musical en una personal. Esta notación proporciona el lenguaje de la música. Los músicos tocando la música de la partitura puede reproducir el tono original y la duración de cada sonido representado.

Interpreter | 61

Lista de verificación 1. Decidir si un lenguaje "poco justificable" ofrece un retorno de la inversión. 2. Definir una gramática de la lengua. 3. Cada mapa de la producción en la gramática para una clase. 4. Organizar el conjunto de la estructura de clases en el patrón Composite. 5. Definir un interpretar(context) método de la jerarquía compuesto. 6. El objeto de contexto encapsula el estado actual de la entrada y salida como la antigua es analizada y la última es acumulado. Es manipulada por cada clase de gramática como "interpretar" el proceso transforma la entrada a la salida.

Reglas del pulgar Considerado en su forma más general (es decir, una operación distribuida en una jerarquía de clases basado en el patrón Composite), casi cada uso del patrón Composite intérprete también contendrá el patrón. Pero el patrón intérprete debe reservarse para aquellos casos en los que quiera pensar de esta jerarquía de clases como la definición de un idioma. Intérprete puede utilizar para definir el análisis de contextos. El árbol de sintaxis abstracta de intérprete es un compuesto (por lo tanto, iterador y visitante también son aplicables). El símbolo terminal dentro del intérprete de árbol de sintaxis abstracta puede ser compartida con contrapeso. El patrón no abordar el análisis. Cuando la gramática es muy compleja, otras técnicas (como un analizador) son más apropiados.

62 | Interpreter

Iterador La intención • Proporcionan una forma de acceder a los elementos de un objeto agregado

secuencialmente sin exponer su representación subyacente. • El C++ de la biblioteca estándar de Java y de abstracción que hace posible separar las

clases de colección y algoritmos. • Promover al estado de objeto "llena" la travesía de una colección. • Trasversal polimorfo

Problema Necesidad de "abstracta" la travesía de radicalmente diferente de las estructuras de datos de modo que se puede definir algoritmos que son capaces de interactuar con cada uno de manera transparente.

Discusión Un objeto agregado como una lista debe darle una forma de acceder a sus elementos sin exponer su estructura interna. Además, es posible que desee para recorrer la lista de diferentes formas, dependiendo de lo que necesite llevar a cabo. Pero probablemente no desea engordar la lista interfaz con las operaciones de recorridos diferentes, incluso si pudiera anticipar los necesitará. También podría ser necesario disponer de más de una pendiente transversal en la misma lista. Y, proporcionando una interfaz uniforme para atravesar muchos tipos de objetos agregados (es decir, la iteración polimórfica) podría ser valiosa. El patrón Iterador. te permite hacer todo esto. La idea clave es la de asumir la responsabilidad por el acceso y el recorrido del objeto agregado y ponerlo en un objeto Iterador que define un protocolo de recorrido estándar. El iterador de la abstracción es fundamental para una nueva tecnología denominada "programación genérica". Esta estrategia pretende explícitamente el concepto de "independiente" a partir de ese algoritmo de " estructura de datos". La motivación es: promover el desarrollo basado en componentes, aumentar la productividad y reducir la gestión de la configuración.

Iterator | 63

Como un ejemplo, si quería apoyar cuatro estructuras de datos (array, Binary Tree, lista enlazada y tabla hash) y tres algoritmos (ordenar, buscar y combinar), un enfoque tradicional requeriría cuatro veces tres variantes de desarrollar y mantener. Mientras, un enfoque de programación genérica sólo necesitaría cuatro más tres elementos de configuración.

Estructura El cliente utiliza la clase de colección' Interfaz pública directamente. Pero el acceso a los elementos de la colección se encuentra encapsulada detrás del nivel adicional de abstracción llamada Iterator. Cada colección sabe qué clase derivada de la clase derivada de iterador para crear y volver. Después de eso, el cliente se basa en la interfaz definida en la clase base del iterador.

Ejemplo El iterador proporciona formas de acceso a los elementos de un objeto agregado secuencialmente sin exponer la estructura subyacente del objeto. Los archivos son Objetos agregados. En la oficina donde el acceso a los archivos se realiza a través de administrativo o de personal de la secretaría, el patrón Iterator queda demostrada con el secretario actuando como el iterador. Varios sketchs de comedia de televisión se han desarrollado en torno a la premisa de un ejecutivo 64 | Iterator

Tratando de entender el sistema de presentación del secretario. Para el ejecutivo, el sistema de archivos es confuso e ilógico, pero el secretario puede acceder a los archivos de forma rápida y eficaz. En los primeros sets de televisión, un cuadrante fue utilizado para cambiar los canales. Cuando el canal del surf, el espectador se necesita para mover el dial a través de cada canal, independientemente de la posición que tenía el canal de recepción. En los modernos televisores, un botón siguiente y anterior son utilizados. Cuando el usuario selecciona el botón "Siguiente", la siguiente se mostrará el canal sintonizado. Considere la posibilidad de ver la televisión en una habitación de hotel en una ciudad extraña. Cuando navega a través de los canales, el número de canal no es importante, pero la programación es. Si la programación de un canal no es de interés, el espectador puede solicitar el siguiente canal, sin saber su número.

Lista de verificación 1. Agregar un método create_iterator para la "colección" class y conceder el "iterador" class acceso privilegiado. 2. Diseñar una "clase" de iterador que puede encapsular el recorrido de la "colección" de clase. 3. Los clientes piden el objeto de colección para crear un objeto Iterator. 4. Los clientes utilizan la primera (), es_done (), siguiente (), y current_item () Protocolo para acceder a los elementos de la clase de colección.

Iterator | 65

Reglas del pulgar El árbol de sintaxis abstracta de intérprete es un compuesto (por lo tanto, iterador y visitante también son aplicables). Iterador puede atravesar un compuesto. Visitante puede aplicar una operación sobre un compuesto. Los iteradores polimórficas se basan en métodos de fábrica para crear una instancia de la subclase iterador apropiado. Memento se utiliza a menudo en conjunción con el iterador. Un iterador puede utilizar un Memento para capturar el estado de la iteración. El iterador almacena el memento internamente.

66 | Iterator

Mediador La intención • Definir un objeto que encapsula un conjunto de cómo interactúan los objetos.

Mediador promueve el acoplamiento flexible por mantener los objetos de referencia a cada otros explícitamente, y permite variar su interacción de manera independiente. • Diseño de un intermediario para separar muchos compañeros. • Promover las relaciones muchos-a-muchos entre interactuando pares a "lleno"

el estado del objeto.

Problema Queremos diseñar componentes reutilizables, pero potencialmente las dependencias entre las partes reutilizables demuestran el fenómeno "spaghetti code" (tratando de boca una sola porción resultados en un cúmulo de "todo o nada").

Discusión En Unix, el permiso de acceso a los recursos del sistema se gestiona en tres niveles de granularidad: world, grupo y propietario. Un grupo es una colección de usuarios destinados al modelo una afiliación funcional. Cada usuario del sistema puede ser miembro de uno o más grupos, y cada grupo puede tener cero o más usuarios asignados a él. La siguiente figura muestra tres usuarios que están asignados a los tres grupos.

Mediator | 67

Si fuéramos a este modelo en software, podríamos decidir tener objetos de usuario junto a un grupo de objetos, y los objetos del grupo junto a los objetos de usuario. A continuación, cuando se producen cambios, tantas clases y todas sus instancias se verían afectados. Un enfoque alternativo sería introducir "un nivel adicional de direccionamiento indirecto" - tome la asignación de usuarios a grupos y grupos a usuarios, y hacen una abstracción en sí mismo. Esto ofrece varias ventajas: Usuarios y grupos están disociados el uno del otro, muchas asignaciones pueden ser fácilmente mantenidas y manipulados de manera simultánea, y la asignación abstracción puede ser ampliada en el futuro mediante la definición de clases derivadas.

Particionar un sistema en muchos objetos generalmente mejora la reusabilidad, pero proliferan las interconexiones entre los objetos tienden a disminuir de nuevo. El mediador objeto: encapsula todas las interconexiones, actúa como el centro de comunicación, es responsable de controlar y coordinar las interacciones de sus clientes, y promueve el acoplamiento flexible por mantener los objetos de referencia a cada otros explícitamente. El mediador promueve un "patrón de relación muchos a muchos network" a "full estado del objeto". Modelización de la inter-relación con un objeto mejora la encapsulación, y permite que el comportamiento de las inter-relaciones para ser modificado o ampliado a través de los sub-clasificadores. Un ejemplo en el que el mediador es útil es el diseño de una capacidad de grupo y usuario en un sistema operativo. Un grupo puede tener cero o más usuarios, y un usuario puede ser miembro de cero o más grupos. El

68 | Mediator

Patrón mediador proporciona una herramienta flexible y no invasivo para asociar y administrar usuarios y grupos.

Estructura

Sus colegas (o pares) no se unirán el uno con el otro. Cada uno hable con el Mediador, que a su vez sabe y realiza la orquestación de los demás. La "asignación de muchos a muchos" entre colegas que podrían existir, ha sido "promovido al estado completo de objeto". Esta nueva abstracción ofrece un locus de direccionamiento indirecto donde un apalancamiento adicional puede ser alojada.

Ejemplo El mediador define un objeto que controla cómo un conjunto de objetos que interactúan. Acoplamiento entre el colega los objetos se logran por tener colegas comunicarse con el mediador, en lugar de unos con otros.

Mediator | 69

La torre de control en un aeropuerto controlado demuestra este patrón muy bien. Los pilotos de los aviones llegando o saliendo de la zona terminal comunicarse con la torre en lugar de comunicar explícitamente el uno con el otro. Las restricciones sobre quién puede aterrizar o despegar son aplicadas por la torre. Es importante señalar que la torre no controla todo el vuelo. Sólo existe para imponer restricciones en el área terminal.

Lista de verificación

1. Identificar una colección de objetos que interactúan, que se beneficiarían de disociación mutua. 2. Encapsular las interacciones en la abstracción de una clase nueva. 3. Crear una instancia de esa clase nueva y rectificación de las "peer" los objetos para interactuar con el Mediador único. 4. Equilibrar el principio de disociación con el principio de la distribución de la responsabilidad de manera uniforme. 5. Tenga cuidado de no crear un "controlador" o "dios" objeto.

Reglas del pulgar Cadena de responsabilidad, mando, mediador y observador, abordar el tema de cómo puede desacoplar los emisores y receptores, pero con diferentes trade-

70 | Mediator

Offs. Cadena de responsabilidad pasa una solicitud del remitente a lo largo de una cadena de potenciales receptores. Comando normalmente especifica una conexión emisor-receptor con una subclase. Mediador ha de emisores y receptores de referencia cada otros indirectamente. Observador define una interfaz muy disociada que permite múltiples receptores para ser configuradas en tiempo de ejecución. Mediador y observador están compitiendo los patrones. La diferencia entre ellos es que el observador distribuye la comunicación mediante la introducción de "observador" y "sujeto" objetos, mientras que un objeto mediador encapsula la comunicación entre otros objetos. Hemos encontrado que es más fácil hacer reutilizables sujetos y observadores que hacer de mediadores reutilizables. Por otro lado, el mediador puede aprovechar el observador dinámicamente para registrar sus compañeros y comunicarse con ellos. Es como mediador en la fachada que abstrae la funcionalidad de las clases existentes. Abstracts/mediador centraliza la comunicación entre objetos arbitrarios colega, rutinariamente "añade valor", y es conocido/referenciado por el colega objetos (es decir, define un protocolo multidireccional). En contraste, la fachada define una interfaz simple para un subsistema, no agrega nueva funcionalidad, y no es conocido por el subsistema de clases (es decir, define un protocolo unidireccional donde realiza peticiones del subsistema clases, pero no viceversa).

Mediator | 71

Memento La intención  Sin violar la encapsulación, captura y desentenderse del estado interno de un objeto, de forma que el objeto pueda ser devuelto a este estado más tarde.  Una cookie mágica que encapsula un "check point" de capacidad.  Promover deshacer o revertir al estado del objeto completo.

Problema Necesita restaurar un objeto vuelve a su estado anterior (deshacer o revertir Las operaciones).

Discusión El cliente solicita un recuerdo desde el objeto de origen cuando se necesita un punto de control del estado del objeto de origen. El objeto de origen inicializa el Memento con una caracterización de su estado. El cliente es el "provisional" del recuerdo, sino sólo el objeto de origen puede almacenar y recuperar información desde el Memento (Memento es "opaco" para el cliente y todos los demás objetos). Si el cliente necesita posteriormente para "revertir" el estado del objeto de origen, manos el memento de vuelta al objeto de origen para la reinstalación. Una cantidad ilimitada de posibilidades para "deshacer" y "rehacer" capacidad puede aplicarse fácilmente con una pila de objetos de comando y una pila de objetos de recuerdo. El patrón de diseño Memento define tres funciones distintas: 1. Iniciador - el objeto que sabe cómo salvar a sí mismo. 2. Cuidador - el objeto que sabe por qué y cuando el iniciador debe guardar y restaurar. 3. Memento - el cuadro de bloqueo que está escrita y leída por el iniciador, y acompañó por el cuidador.

72 | Memento

Estructura

Ejemplo El Memento captura y externalizes del estado interno de un objeto, de forma que el objeto pueda ser restaurada posteriormente a ese estado. Este patrón es común entre do-it-yourself mecánica reparación de frenos de tambor en sus coches. Los tambores son removidos desde ambos lados, exponiendo los frenos derecho e izquierdo. Sólo un lado está desmontado y el otro sirve como un recuerdo de cómo encajan las piezas del freno. Sólo después de que el trabajo ha sido completado por un lado está el otro lado desmontado. Cuando se desmonta la segunda cara, la primera cara actúa como recuerdo.

Memento | 73

Lista de verificación 1. Identificar las funciones de "cuidador" y "iniciador". 2. Crear una clase de Memento y declarar el iniciador de un amigo. 3. Cuidador sabe cuándo "check point" el iniciador. 4. Iniciador crea un memento y copias de su estado para que Memento. 5. Cuidador tiene a (pero no pueden asomarse a) el memento. 6. Cuidador sabe cuándo "revertir" el iniciador. 7. Iniciador restituye automáticamente utilizando el estado guardado en el recuerdo.

Reglas del pulgar Mando y Memento actúan como magic tokens para ser circular y se invoca más adelante. En el comando, el símbolo representa una solicitud; en Memento, representa el estado interno de un objeto a la vez. El polimorfismo es importante comando, pero no recuerdo porque su interfaz es tan estrecha que un recuerdo sólo puede ser pasado como un valor. Puede utilizar el comando Memento para mantener el estado requerido para una operación de deshacer. Memento se utiliza a menudo en conjunción con el iterador. Un iterador puede utilizar un Memento para capturar el estado de la iteración. El iterador almacena el memento internamente.

74 | Memento

Objeto Null La intención La intención de un objeto nulo para encapsular la ausencia de un objeto, proporcionando unas alternativas sustituibles que ofrece el comportamiento predeterminado adecuado no hacer nada. En definitiva, un diseño en el que "nada vendrá de la nada" Utilice el patrón de objeto nulo cuando: • Un objeto requiere un colaborador. El objeto nulo patrón no introducir esta

colaboración--hace uso de una colaboración que ya existe. • Algunas instancias de colaborador no deberían hacer nada • Desea resumen el manejo de null lejos del cliente

Problema Dado que una referencia de objeto puede opcionalmente ser nulo, y que el resultado de una comprobación de null es no hacer nada o utilizar algún valor predeterminado, ¿cómo es posible que la ausencia de un objeto - la presencia de una referencia null - ser tratada de forma transparente?

Discusión A veces una clase que requiere un colaborador no necesita el colaborador para hacer cualquier cosa. Sin embargo, la clase que desea tratar un colaborador que no hace nada de la misma manera como se trata a uno que proporciona el comportamiento. Considere, por ejemplo, un simple salvapantallas que muestra bolas que se mueven por la pantalla y tienen efectos de color especiales. Esto se consigue fácilmente mediante la creación de una bola de clase para representar las bolas y utilizando un modelo de estrategia para controlar al movimiento de la pelota y otro patrón de estrategia para controlar la bola de color. Entonces, sería trivial para escribir estrategias para muchos diferentes tipos de movimiento y efectos de color y crear las bolas con cualquier combinación de estos. Sin embargo, comenzar con usted desea crear las estrategias más simples

Null Object | 75

Posible para asegurarnos de que todo funciona. Y esas estrategias podrían también ser útiles más adelante ya que desea como estrategias como posibles estrategias.

Ahora, la estrategia más simple sería ninguna estrategia. Eso es no hacer nada, no se mueven y no cambian de color. Sin embargo, la pauta de estrategia requiere la bola para tener objetos que implementan la estrategia de interfaces. Aquí es donde el patrón Objeto nulo se vuelve útil. Basta con implementar un NullMovementStrategy que no mueve la bola y un NullColorStrategy que no cambia el color de la bola. Ambos probablemente puedan ser implementado esencialmente sin código. Todos los métodos de estas clases de hacer "nada". Son perfectos ejemplos del patrón de objeto nulo. La clave para el objeto nulo patrón es una clase abstracta que define la interfaz de todos los objetos de este tipo. El objeto nulo se implementa como una subclase de esta clase abstracta. Porque se ajusta a la clase abstracta" interfaz, que puede ser utilizado en cualquier lugar este tipo de objeto es necesario. En comparación con un valor "null" especial que no implementa la interfaz abstracta, y que constantemente debe comprobarse con un código especial en cualquier objeto que utiliza la interfaz abstracta. A veces se piensa que los objetos nulos son más simples y "estúpido" pero que en verdad un objeto Null siempre sabe exactamente lo que necesita

76 | Null Object

Hacerse sin interactuar con otros objetos. Así, en verdad es muy "inteligentes".

Estructura

Cliente

•

Requiere un colaborador

Objeto abstracto

• •

Declara la interfaz para colaborador del cliente Implementa el comportamiento por defecto de la interfaz común a todas las clases, según corresponda

Objeto real

•

Define una subclase concreta del objeto abstracto cuyas instancias proporcionar comportamiento útil que el Cliente espera

Objeto Null

• •

•

Proporciona una interfaz idéntica al objeto abstracto, de modo que un objeto nulo puede ser sustituido por un objeto real Implementa su interfaz para no hacer nada. Qué es exactamente lo que significa no hacer nada depende de qué tipo de comportamiento cliente está esperando Cuando hay más de una manera de no hacer nada, más de una clase de objeto nulo puede ser requerido

Reglas del pulgar La clase de objeto nulo se suele implementar como un singleton. Desde un objeto null normalmente no tiene ningún estado, su estado no se puede cambiar, por lo que Null Object | 77

Varias instancias son idénticos. En lugar de utilizar varias instancias idénticas, el sistema sólo puede utilizar una única instancia repetidamente. Si algunos clientes esperan que el objeto nulo para no hacer nada de una manera y otra, varias clases de objeto nulo será necesaria. Si el comportamiento No hacer nada debe ser personalizado en tiempo de ejecución, la clase de objeto nulo requerirá pluggable variables, de modo que el cliente puede especificar cómo el objeto nulo no debe hacer nada (véase la discusión de adaptadores adaptador enchufable en el patrón). En general, esto puede ser un síntoma de un objeto abstracto no tener una bien definida (semántica) interfaz. Un objeto nulo no se transforma para convertirse en un objeto real. Si el objeto puede decidir dejar de proporcionar el comportamiento de no hacer nada y empezar a proporcionar comportamiento real, no es un objeto nulo. Puede ser un objeto real con un modo de no hacer nada, como un controlador que puede encender y apagar el modo de sólo lectura. Si se trata de un único objeto que debe mutar desde un objeto de no hacer nada a uno real, deben ser aplicadas con el Estado patrón o quizás el patrón Proxy. En este caso un estado nulo puede ser utilizado, o el proxy puede sostener un objeto nulo. El uso de un objeto null puede ser igual que el de un proxy, pero los dos patrones tienen propósitos diferentes. Un proxy proporciona un nivel de direccionamiento indirecto cuando se accede a un sujeto real, controlando así el acceso al objeto. Un colaborador de null no oculta un objeto real y controlar el acceso a la misma, se reemplaza el objeto real. Un proxy puede eventualmente mutar para empezar a actuar como un sujeto real. Unos objetos nulos no mutan para empezar a proporcionar comportamiento real, siempre proporcionará el comportamiento de no hacer nada. Un objeto nulo puede ser un caso especial de la Estrategia de patrones. Estrategia especifica varias clases ConcreteStrategy como diferentes enfoques para llevar a cabo una tarea. Si uno de estos enfoques es no hacer nada, siempre que ConcreteStrategy es un objeto Null. Por ejemplo, un controlador de la vista es una estrategia para la gestión de la entrada, y ningún controlador es la estrategia que ignora todas las entradas. Un objeto nulo puede ser un caso especial del Estado patrón. Normalmente, cada ConcreteState tiene algunos métodos de hacer nada porque no son apropiadas para ese estado. De hecho, un determinado método se implementa a menudo

78 | Null Object

Para hacer algo útil en la mayoría de los estados, pero no hacer nada en al menos un estado. Si un ConcreteState implementa la mayoría de sus métodos para no hacer nada o, al menos, dar resultados nulos, se convierte en un estado de no hacer nada y, como tal, es un estado nulo. Un objeto nulo puede usarse para permitir que un visitante visita de forma segura una jerarquía y manejar la situación nulo. Objeto nulo es un colaborador concreto clase que actúa como colaborador para un cliente que necesita uno. El comportamiento null no está diseñado para ser mezclado en un objeto que necesita de algún comportamiento de no hacer nada. Está diseñado para una clase que delega a un colaborador que todos los comportamientos que pueden o no pueden hacer nada de comportamiento.

Null Object | 79

Agrupación de objetos La intención Agrupación de objetos puede ofrecer un aumento significativo del rendimiento; es más efectivo en situaciones donde el costo de inicializar una instancia de clase alta, la tasa de instancia de una clase es alta, y el número de instancias en uso en cualquier momento es baja.

Problema Piscinas de objeto (también conocido como pools de recursos) se utilizan para administrar el almacenamiento en caché de objetos. Un cliente con acceso a la piscina de un objeto puede evitar la creación de nuevos objetos por simplemente preguntar a la piscina por uno que ya ha sido instanciado en su lugar. Generalmente, la piscina será un grupo creciente, es decir, la piscina en sí va a crear nuevos objetos si la piscina está vacía, o podemos tener una piscina, que limita el número de objetos creados. Es conveniente conservar todos los objetos reutilizables que no están actualmente en uso en la misma agrupación de objetos para que puedan ser gestionados por una política coherente. Para lograr esto, la agrupación de reutilizables clases está diseñada para ser una clase singleton.

Discusión La Agrupación de objetos permite a otros "verificar" los objetos de su agrupación, cuando aquellos objetos que ya no son necesarios para sus procesos se devuelven a la agrupación para ser reutilizados. Sin embargo, no queremos un proceso de tener que esperar que un objeto sea liberado, por lo que el objeto Pool también crea nuevos objetos a medida que son necesarios, sino que también debe implementar un mecanismo para limpiar periódicamente los objetos no utilizados.

Estructura La idea general de la agrupación de conexiones patrón es que, si las instancias de una clase pueden ser reutilizados, evitar la creación de instancias de la clase mediante la reutilización de los mismos. 80 | Object Pool

- Las instancias de clases reutilizables en este papel, colaborar con otros objetos durante un período de tiempo limitado y, a continuación, ya no son necesarios para esa colaboración. Cliente -

instancias de clases en esta función utilizar objetos reutilizables.

- ReusablePool instancias de clases en esta función administrar objetos reutilizables para objetos de uso por parte del cliente.

Normalmente, es conveniente para mantener todos los objetos reutilizables que no están actualmente en uso en la misma agrupación de objetos para que puedan ser gestionados por una política coherente. Para lograr esto, la clase ReusablePool está diseñado para ser una clase singleton. Su constructor(s) son privados, lo cual obliga a otras clases para llamar a su método GetInstance para obtener una instancia de la clase ReusablePool. Un objeto cliente llama a un método del objeto ReusablePool acquireReusable cuando necesita un objeto reutilizable. Un objeto ReusablePool mantiene una colección de objetos reutilizables. Se utiliza la colección de objetos reutilizables que contienen un conjunto de objetos reutilizables que actualmente no están en uso. Si hay objetos reutilizables en la piscina cuando el método se llama acquireReusable, quita un objeto reutilizable desde la piscina y lo devuelve. Si la piscina está vacía, el método acquireReusable crea un objeto reutilizable si se puede. Si el método acquireReusable no puede crear un nuevo objeto reutilizable, entonces espera hasta que un objeto reutilizable es devuelto a la colección. Objetos de cliente pasa un objeto reutilizable a un método del objeto ReusablePool releaseReusable cuando hayan terminado con el objeto. El método releaseReusable devuelve un objeto reutilizable a la agrupación de objetos reutilizables que no estén en uso.

Object Pool | 81

En muchas aplicaciones del objeto Pool patrón, hay motivos para limitar el número total de objetos reutilizables que puedan existir. En tales casos, el objeto ReusablePool que crea objetos reutilizables es responsable de no crear más de un determinado número máximo de objetos reutilizables. Si ReusablePool objetos son responsables de limitar el número de objetos que se van a crear, y luego la ReusablePool clase tendrá un método para especificar el número máximo de objetos que se va a crear. El método que se indica en el diagrama anterior como setMaxPoolSize.

Ejemplo ¿Te gustan los bolos? Si usted lo hace, usted probablemente sabe que debe cambiar los zapatos cuando usted está recibiendo el club de bolos. Estantería Zapata es maravilloso ejemplo de un conjunto de objetos. Una vez que usted desea jugar, usted obtendrá su pareja (aquireReusable). Después del juego, volverás zapatos vuelve a la estantería (releaseReusable).

82 | Object Pool

Lista de verificación 1. Crear clase ObjectPool con matriz privado dentro de objeto 2. Crear acquare y suelte los métodos en la clase ObjectPool 3. Asegúrese de que su ObjectPool es Singleton.

Reglas del pulgar El patrón Factory Method puede ser utilizado para encapsular la lógica de creación de objetos. Sin embargo, no administrar ellos después de su creación, la agrupación de objetos modelo mantiene el seguimiento de los objetos que crea. Las memorias objeto se implementa normalmente como singletons.

Object Pool | 83

Observador La intención  Definir un uno-a-mucha dependencia entre objetos de manera que cuando un objeto

cambia de estado, todos sus dependientes son notificados y actualizados automáticamente.  Encapsular el núcleo (o común) los componentes del motor o en un tema abstracto, y

la variable (u opcional) los componentes de la interfaz de usuario o en la jerarquía de un observador.  El "punto de vista" parte de Model-View-Controller.

Problema Un gran diseño monolítico no escala bien como nuevos gráficos o los requisitos de control son percibidos.

Discusión Definir un objeto que es el "guardián" del modelo de datos y/o lógica de negocios (el sujeto). Delegado toda la funcionalidad de "ver" a la disociada y distintos objetos de observación. Los observadores se registran con el tema a medida que se crean. Cuando el tema cambia, difunde a todos los observadores inscritos que ha cambiado, y cada observador consulta el tema para ese subconjunto del estado del sujeto que es responsable de la supervisión. El protocolo descrito anteriormente especifica un modelo de interacción "pull". En lugar de la asignatura "empujando" ¿Qué ha cambiado para todos los observadores, cada observador se encarga de "tirar" de su particular "ventana de interés" en el asunto. El modelo "push" compromete la reutilización, mientras que el modelo "pull" es menos eficiente. Las cuestiones que se discuten, pero deja a la discreción del diseñador, incluyen: implementación de compresión de eventos (sólo enviar un único cambio tras la difusión de una serie de cambios consecutivos se ha producido), habiendo un solo observador, monitorización de varios temas, y asegurándose de que un sujeto notificar a sus observadores cuando está a punto de desaparecer.

84 | Observer

El patrón Observer. capta la mayor parte del patrón Model-View-Controller arquitectura que ha sido parte de la comunidad Smalltalk durante años.

Estructura

Asunto representa el núcleo (o independientes o comunes o motor) de la abstracción. Observador representa la variable (o dependiente u opcional o interfaz de usuario) de la abstracción. El tema pide al observador de objetos para hacer sus cosas. Cada observador puede volver a llamar a los sujetos según sea necesario.

Ejemplo El observador define una relación uno a varios, de manera que cuando un objeto cambia de estado, los otros son notificadas y se actualiza automáticamente. Algunas subastas demuestran este patrón. Cada postor posee una paleta numerada que se usa para indicar una puja. El subastador inicia la licitación, y "observa" cuando una paleta se planteó para aceptar la oferta. La aceptación de la oferta se cambia el precio de puja que se difunde a todos los licitadores en la forma de una nueva oferta.

Observer | 85

Lista de verificación 1. Diferenciar entre el núcleo (o independientes) y la funcionalidad opcional (o dependiente) funcionalidad. 2. Las funciones independientes de modelo con un "sujeto" de la abstracción. 3. Funciones dependientes del modelo con una jerarquía de "observadores". 4. El sujeto está unida sólo a la clase base de observación. 5. El cliente configura el número y tipo de observadores. 6. Los observadores se registran con el tema. 7. El tema difunde eventos a todos los observadores inscritos. 8. El sujeto puede "empujar" información a los observadores o, los observadores pueden "tirar" la información que necesitan desde el sujeto.

Reglas del pulgar Cadena de responsabilidad, mando, mediador y observador, abordar el tema de cómo puede desacoplar los emisores y receptores, pero con diferentes compensaciones recíprocas. Cadena de responsabilidad pasa una solicitud del remitente a lo largo de una cadena de potenciales receptores. Comando normalmente especifica una conexión emisor-receptor con una subclase. Mediador ha de emisores y receptores 86 | Observer

Cada referencia otras indirectamente. Observador define una interfaz muy disociada que permite múltiples receptores para ser configuradas en tiempo de ejecución. Mediador y observador están compitiendo los patrones. La diferencia entre ellos es que el observador distribuye la comunicación mediante la introducción de "observador" y "sujeto" objetos, mientras que un objeto mediador encapsula la comunicación entre otros objetos. Hemos encontrado que es más fácil hacer reutilizables sujetos y observadores que hacer de mediadores reutilizables. Por otro lado, el mediador puede aprovechar el observador dinámicamente para registrar sus compañeros y comunicarse con ellos.

Observer | 87

Datos de clase privada La intención •

Controlar el acceso de escritura a los atributos de la clase

•

Separar los datos de los métodos que utilizan

•

Encapsular la inicialización de datos de clase

•

Proporcionar un nuevo tipo de final - final después de constructor

Problema Una clase puede exponer sus atributos (variables de clase) a la manipulación cuando la manipulación ya no es deseable, por ejemplo, después de la construcción. Utilizando el patrón de diseño de datos de clase privada impide que la manipulación indeseable. Una clase puede tener una sola vez atributos mutable que no puede declararse como final. Usando este patrón de diseño permite un ajuste de tiempo de los atributos de clase. La motivación de este patrón de diseño viene desde el diseño el objetivo de proteger a la clase estado minimizando la visibilidad de sus atributos (datos).

Discusión El patrón de diseño de datos de clase privada pretende reducir la exposición de los atributos por limitar su visibilidad. Reduce el número de atributos de clase encapsulándolos en solo un objeto de datos. Permite al diseñador de clases para quitar privilegios de escritura de atributos que se van a establecer sólo durante la construcción, incluso desde los métodos de la clase de destino.

Estructura El patrón de diseño de datos de clase privada resuelve los problemas anteriores extrayendo una clase de datos para la clase de destino y dando a la instancia de la clase de destino de una instancia de la clase de datos extraídos.

88 | Private Class Data

Lista de verificación 1. Crear la clase de datos. Mover a todos los atributos de la clase de datos que necesitan esconderse. 2. Crear en clase principal instancia de clase de datos. 3. Clase principal debe inicializar la clase de datos a través del constructor de la clase de datos. 4. Exponer cada atributo (variable o propiedad) de datos clase mediante un getter. 5. Exponer cada atributo que cambiarán aún más mediante un Setter.

Private Class Data | 89

Prototipo La intención  Especificar los tipos de objetos para crear mediante una instancia prototípica, y crear

nuevos objetos copiando este prototipo.  Cooptar una instancia de una clase para usar como un criador de todas las

repeticiones futuras.  El nuevo operador considerados dañinos.

Problema La aplicación "cables duros" la clase de objeto que se va a crear en cada uno de los "nuevos" de expresión.

Discusión Declarar una clase base abstracta que especifica un "clon virtual pura" método, y mantiene un diccionario de todos los "clonable" concreto clases derivadas. Cualquier clase que necesita un "constructor" polimórfica capacidad: se deriva de la clase base abstracta, registra su instancia prototípica, y ejecuta la operación de clonación. A continuación, el cliente, en lugar de escribir código que invoca el operador "new" en un nombre de clase alámbricos, llama un "clon" de la operación en la clase base abstracta, suministrando una cadena o un tipo de datos enumerado que designa la clase derivada concreta deseada.

Estructura La fábrica sabe cómo encontrar el prototipo correcto, y cada producto sabe cómo generar nuevas instancias de sí mismo.

90 | Prototype

Ejemplo El patrón prototipo especifica el tipo de objetos para crear utilizando un ejemplo prototípico. Prototipos de nuevos productos son a menudo fabricados con anterioridad a la plena producción, pero en este ejemplo, el prototipo es pasivo y no participar en copias de sí mismo. La división mitótica de una célula, dando lugar a dos células idénticas - es un ejemplo de un prototipo que desempeña un papel activo en la copia de sí mismo y, por lo tanto, demuestra el patrón prototipo. Cuando una célula se divide, dos celdas de genotipo idéntico resultado. En otras palabras, los clones celulares.

Prototype | 91

Lista de verificación 1. Agregar un método clone de la jerarquía existente de "producto". 2. El diseño de un "registro" que mantiene una caché de objetos prototípicos. El registro podría ser encapsulado en una nueva fábrica de clase o en la clase base de la jerarquía de "producto". 3. Diseñar un método de fábrica que pueden (o no) que aceptan argumentos, busca el objeto prototipo correcto, llamadas clon en ese objeto y devuelve el resultado. 4. El cliente reemplaza todas las referencias al nuevo operador con llamadas al método de fábrica.

Reglas del pulgar Patrones de creación a veces son competidores: hay casos cuando cualquiera de los prototipos o Fábrica Abstracta podría ser utilizado correctamente. Otras veces son complementarias: Abstract Factory puede almacenar un conjunto de prototipos para clonar y devolver objetos de producto. Fábrica Abstracta, constructor y prototipo puede utilizar Singleton en sus implementaciones. Clases Abstract Factory suelen realizarse con métodos de fábrica, pero pueden implementarse a través de prototipo. Método de fábrica: creación a través de la herencia. Prototipo: creación a través de la delegación. A menudo, los diseños comiencen utilizando el método Factory (menos complicada, más personalizable, proliferan las subclases) y evolucionar hacia la Fábrica Abstracta, prototipos o Builder (más flexible, más complejo) como el diseñador descubre dónde se requiere más flexibilidad. Prototipo no requiere sub clasificadores, pero requiere una operación "inicializar". Método de fábrica requiere sub clasificadores, pero no requiere la inicialización. Los diseños que hacen un uso intensivo del composite y decorador patrones muchas veces pueden beneficiarse del prototipo.

92 | Prototype

Prototipo co-opts una instancia de una clase para usar como un criador de todas las repeticiones futuras. Los prototipos son útiles cuando la inicialización del objeto es costosa, y puede anticipar algunas variaciones en los parámetros de inicialización. En este contexto, el prototipo puede evitar costosos "Creación desde cero", y el apoyo económico de la clonación de un pre-inicializado prototipo. Prototipo es único entre los demás patrones de creación ya que no es necesario que una clase - sólo un objeto. Los lenguajes orientados a objetos como legítima y Omega que acabar con las clases confiar totalmente en prototipos para crear nuevos objetos.

Prototype | 93

Proxy La intención  Proporcionar un sustituto o marcador para otro objeto para controlar el acceso

a ella.  Utilice un nivel extra de direccionamiento indirecto para apoyar distribuido, controlado,

o de acceso inteligente.  Agregar un contenedor y la delegación para proteger el componente real de

una complejidad innecesaria.

Problema Necesita soporte para objetos que consumen muchos recursos, y no desea crear instancias de estos objetos a menos que y hasta que son solicitados por el cliente.

Discusión Diseño de un sustituto, o proxy, objeto que: crea una instancia del objeto real la primera vez que el cliente realiza una petición del proxy, recuerda la identidad de este objeto real, instigar y reenvía la petición a este objeto real. Entonces todas las solicitudes posteriores son simplemente reenvía directamente al objeto real encapsulada. Hay cuatro situaciones comunes en las que el patrón Proxy es aplicable. 1. Un proxy virtual es un marcador de posición para "caro" para crear objetos. El objeto real sólo se crea cuando un cliente primero solicitudes/accede al objeto. 2. Un proxy remoto proporciona un representante local para un objeto que reside en un espacio de direcciones diferentes. Esto es lo que el código "auxiliar" en RPC y CORBA proporciona.

94 | Proxy

3. Un proxy de protección sensible controla el acceso a un objeto Máster. El "sustituto" objeto comprueba que el llamador tiene los permisos de acceso requeridos antes de enviar la solicitud. 4. Un proxy inteligente interpone acciones adicionales cuando se accede a un objeto. Los usos típicos incluyen: o Contando el número de referencias al objeto real a fin de que pueda ser liberada

automáticamente cuando no hay más referencias (aka puntero inteligente), o Cargar un objeto persistente en la memoria cuando es la primera

referencia, o Comprobando que el objeto real está bloqueado antes de que accede a

asegurar que ningún otro objeto puede cambiar.

Estructura Mediante la definición de un objeto de interfaz, la presencia permanente del objeto proxy en lugar del sujeto real es transparente para el cliente.

Ejemplo El proxy proporciona un suplente o titular del lugar para proporcionar acceso a un objeto. Un cheque o giro bancario es un proxy para los fondos en la cuenta. Un cheque puede ser utilizado en lugar de dinero en efectivo para hacer compras y, en definitiva, controla el acceso a dinero en efectivo en la cuenta del emisor. Proxy | 95

Lista de verificación 1. Identificar la influencia o "aspecto" que mejor se implementa como un contenedor o sucedáneo. 2. Definir una interfaz que hará que el proxy y el componente original intercambiables. 3. Considere la posibilidad de definir una fábrica que puede encapsular la decisión de si un proxy o un objeto original es deseable. 4. La clase contenedora contiene un puntero a la clase real e implementa la interfaz. 5. El puntero puede ser inicializada en construcción, o cuando se utilice por primera vez. 6. Cada método de ajustador contribuye con su apalancamiento y delegados del objeto contenedor.

Reglas del pulgar Adaptador proporciona una interfaz diferente a su objeto. Proxy ofrece la misma interfaz. Decorador proporciona una interfaz mejorada. Decorador y Proxy tienen propósitos diferentes pero estructuras similares. Ambos describen cómo proporcionar un nivel de direccionamiento indirecto a otro objeto, y las implementaciones mantener una referencia al objeto al que reenviar solicitudes.

96 | Proxy

Singleton. La intención • Garantizar una clase tiene sólo una instancia y proporcionar un punto de acceso

global a ella. • Encapsula "just-in-time" o "Inicialización la inicialización en el primer uso".

Problema Aplicación necesita una, y sólo una instancia de un objeto. Además, la inicialización diferida y acceso global son necesarios.

Discusión Hacer la clase del objeto de instancia única responsable de la creación, inicialización, acceso y aplicación. Declarar la instancia como un miembro de datos estático privado. Proporcionar una función miembro estática pública que encapsula todo el código de inicialización, y proporciona acceso a la instancia. El cliente llama a la función de descriptor de acceso (usando el nombre de la clase y el operador de resolución de ámbito) siempre que una referencia a la instancia única es necesaria. Singleton sólo debe considerarse si los tres de los siguientes criterios se cumplen: • Propiedad de la única instancia no puede ser razonablemente asignados • Inicialización diferida es deseable • Acceso global no está prevista

Si la propiedad de la única instancia, cuándo y cómo se produce la inicialización y acceso global no son problemas, Singleton no es lo suficientemente interesante. El patrón Singleton puede ser extendido para apoyar el acceso a una aplicación específica número de instancias. "La función miembro estática accessor" enfoque no dará soporte sub calificó de la clase Singleton. Si sub clasificadores es deseado, consulte la discusión en el libro.

Singleton | 97

Estructura

Hacer la clase de la instancia única responsable del acceso y de la "inicialización al utilizar por primera vez". La única instancia es un atributo private static. El descriptor de acceso función es un método estático público.

Ejemplo El patrón Singleton garantiza que una clase tiene sólo una instancia y proporciona un punto de acceso global a dicha instancia. Es nombrado después de que el conjunto de singleton, que se define como un conjunto que contiene un elemento. La oficina del presidente de los Estados Unidos es un singleton. La Constitución de los Estados Unidos especifica cómo un presidente es elegido, limita la duración de los mandatos, y define el orden de sucesión. Como resultado, puede haber más de un presidente activo en cualquier momento dado. Independientemente de la identidad personal del presidente activo, el título, "El Presidente de los Estados Unidos" es un punto de acceso global que identifica a la persona en la oficina.

98 | Singleton

Lista de verificación 1. Definir un atributo private static en la clase "única instancia". 2. Definir una función de descriptor de acceso público estático de la clase. 3. Hacer "inicialización diferida" (creación de primer uso) en la función de descriptor de acceso. 4. Definir todos los constructores para ser protegidos o privados. 5. Los clientes sólo pueden utilizar la función de descriptor de acceso para manipular el Singleton.

Reglas del pulgar Fábrica Abstracta, constructor y prototipo puede utilizar Singleton en su aplicación. Fachada objetos son a menudo Singletons porque sólo una fachada objeto es requerida. Estado objetos son a menudo singletons. La ventaja de Singleton en variables globales es que usted está seguro de la cantidad de instancias cuando utilice Singleton, y usted puede cambiar su mente y gestionar cualquier número de instancias. El patrón de diseño Singleton es uno de los patrones más utilizados inadecuadamente. Singletons están destinadas a ser utilizadas cuando una clase debe tener exactamente una instancia, ni más ni menos. Los diseñadores suelen utilizar Singletons en un equivocado intento de sustituir las variables globales. Un Singleton es, para los fines y propósitos, una variable global. Singleton no acaba con la global, sino que simplemente cambia de nombre. Cuando Singleton es innecesaria? Respuesta corta: la mayoría del tiempo. Respuesta larga: cuando es más fácil pasar un objeto recurso como una referencia a los objetos que lo necesitan, en lugar de permitir acceso a objetos del recurso a nivel mundial. El verdadero problema con singletons es que te dan una buena excusa para no pensar cuidadosamente acerca de la adecuada visibilidad de un

Singleton | 99

Objeto. Encontrar el equilibrio correcto de la exposición y de la protección de un objeto es crítico para mantener la flexibilidad. Nuestro grupo tenía un mal hábito de utilizando los datos globales, por lo que hice un grupo de estudio sobre Singleton. La siguiente cosa que sé Singletons apareció en todas partes y ninguno de los problemas relacionados con los datos globales se marchó. La respuesta a la cuestión de los datos globales no es "hacer un singleton". La respuesta es, "¿Por qué diablos estás utilizando los datos globales?" cambiando el nombre no cambia el problema. De hecho, puede empeorarlo porque te da la oportunidad de decir, "Así que no estoy haciendo eso, estoy haciendo este" - aunque esto y que son la misma cosa.

100 | Singleton

Estado La intención • Permitir que un objeto modifique su comportamiento cuando cambia su estado interno.

El objeto aparecerá para cambiar su clase. • Un estado orientado a objetos machines • Wrapper wrapper polimórfico + + colaboración

Problema Un monolítico comportamiento del objeto es una función de su estado, y debe cambiar su comportamiento en tiempo de ejecución dependiendo de ese estado. O bien, una aplicación se caracteriza por grandes y numerosos casos de declaraciones que el vector flujo de control basado en el estado de la aplicación.

Discusión El Estado patrón es una solución al problema de cómo hacer que el comportamiento depende de estado. • Definir una clase "contexto" para presentar una interfaz única para el mundo

exterior. • Definir una clase base abstracta del Estado. • Representan los diferentes "Estados" de la máquina de estado como estado de

las clases derivadas de la clase base. • Definir el comportamiento específico del estado en el estado apropiado en clases

derivadas. • Mantener un puntero a la actual "estado" en la clase de "contexto". • Para cambiar el estado de la máquina de estado, cambiar el estado actual de

"puntero". El Estado patrón no especificar dónde las transiciones de estado serán definidas. Las opciones son dos: el "contexto", objeto o cada Estado clase derivada. La ventaja de la segunda opción es la facilidad de agregar nuevas clases derivadas del Estado. La desventaja es que cada Estado tenga conocimiento de la clase derivada (acoplamiento) a sus hermanos, que introduce las dependencias entre las subclases. State | 101

Un enfoque impulsado por la mesa para el diseño de máquinas de estado finito hace un buen trabajo de especificación de transiciones de estado, pero es difícil añadir acciones para acompañar a las transiciones de estado. El enfoque basado en patrones utiliza un código (en lugar de las estructuras de datos) para especificar transiciones de estado, pero hace un buen trabajo de acomodar las acciones de transición de estado.

Estructura La interfaz de la máquina de estado está encapsulada en la clase "contenedor". Jerarquía de la enrolladora de espejos de la interfaz, la interfaz de la enrolladora salvo para un parámetro adicional. El parámetro adicional permite wrapper clases derivadas para volver a llamar a la clase contenedora como sea necesario. La complejidad que, de lo contrario, arrastre hacia abajo la clase contenedora es perfectamente compartimentados y encapsulado en una jerarquía polimórfica al que el objeto contenedor delegados.

Ejemplo El Estado patrón permite a un objeto para cambiar su comportamiento cuando cambia su estado interno. Este patrón puede ser observada en una máquina expendedora. Las máquinas expendedoras han estados basados en el inventario, la cantidad de moneda 102 | State

Depositados, la habilidad para hacer el cambio, el elemento seleccionado, etc. cuando la moneda es depositado, y se hace una selección, una máquina expendedora o la entrega de un producto y no cambiar, la entrega de un producto y cambio, entregar ningún producto debido a la falta de moneda fuerte, o entregar ningún producto debido al agotamiento del inventario.

Lista de verificación 1. Identificar una clase existente o crear una nueva clase, que servirá como el "estado" de la máquina desde la perspectiva del cliente. Esta clase es la clase "contenedor". 2. Crear una clase base estatal que replica los métodos de la interfaz de la máquina de estado. Cada método toma un parámetro adicional: una instancia de la clase contenedora. El estado de la clase base útil especifica cualquier comportamiento "default". 3. Crear una clase derivada de estado para cada dominio del Estado. Estas clases derivadas sólo invalidar los métodos que necesitan reemplazo. 4. La clase contenedora mantiene un objeto de estado "actual". 5. Todas las solicitudes de cliente a la clase contenedora son simplemente delega en el estado actual, y el objeto del objeto contenedor este puntero se pasa. 6. El estado los métodos cambian el estado "actual" en el objeto contenedor según corresponda.

State | 103

Reglas del pulgar Estado objetos son a menudo singletons. Mazarota Estado describe cuándo y cómo los objetos pueden ser compartidos. Intérprete puede utilizar para definir el análisis de contextos. La estrategia tiene dos implementaciones diferentes, la primera es como Estado. La diferencia está en los tiempos de enlace (Estrategia es un patrón de bind-una vez, mientras que el Estado es más dinámico). La estructura del Estado y el puente son idénticas (excepto que admite el puente sobre las jerarquías de clases, mientras que el Estado sólo permite uno). Los dos modelos utilizan la misma estructura para solucionar diferentes problemas: Estado permite un comportamiento del objeto para cambiar junto con su estado, mientras que el puente es la intención de desvincular una abstracción de su implementación, de manera que los dos pueden variar de forma independiente. La aplicación del modelo de Estado se basa en la estrategia de patrones. La diferencia entre el estado y la estrategia está en la intención. Con la estrategia, la elección del algoritmo es estable. Con el Estado, un cambio en el estado del objeto "Contexto" hace que se seleccione en su estrategia de "paleta" de objetos.

104 | State

Estrategia La intención • Define una familia de algoritmos, encapsular cada uno, y hacerlos intercambiables. La

estrategia permite que el algoritmo varíe independientemente de los clientes que lo usen. • Capturar la abstracción en una interfaz, enterrar los detalles de implementación en las

clases derivadas.

Problema Una de las principales estrategias de diseño orientado a objetos es el "abiertocerrado de principio". La figura muestra cómo esto se logra de manera rutinaria - encapsular los detalles de la interfaz en una clase base, y enterrar los detalles de implementación en las clases derivadas. Los clientes pueden entonces par a una interfaz, y no tener que experimentar los trastornos asociados con el cambio: sin efecto cuando el número de clases derivadas de cambios y ningún impacto cuando la ejecución de una clase derivada cambia.

Un valor genérico de la comunidad de software durante años ha sido "cohesión maximizar y minimizar el acoplamiento". El enfoque de diseño orientado a objetos que se muestra en la figura es todo acerca de minimizar el acoplamiento.

Strategy | 105

Desde que el cliente está acoplado únicamente a una abstracción (es decir, una ficción útil), y no una realización de esa abstracción, el cliente podría decirse que es practicar el "acoplamiento" abstracto . Una variante orientada a objetos de la exhortación más genérica "minimizar el acoplamiento". Unas caracterizaciones más populares de este "acoplamiento" abstracto principio es "Programa para una interfaz, no una aplicación". Los clientes deberían preferir "el nivel adicional de direccionamiento indirecto" que una interfaz (o una clase base abstracta) brinda. La interfaz captura la abstracción (es decir, la "ficción útil") el cliente quiere ejercer, y las implementaciones de la interfaz que efectivamente están ocultas.

Estructura La interfaz entidad podría representar una clase base abstracta, o la firma del método previsto por el cliente. En el primer caso, la jerarquía de herencia representa el polimorfismo dinámico. En este último caso, la entidad representa la interfaz de código de plantilla en el cliente y en la jerarquía de herencia representa el polimorfismo estático.

Ejemplo Una estrategia define un conjunto de algoritmos que pueden utilizarse indistintamente.

106 | Strategy

Modos de transporte a un aeropuerto es un ejemplo de una estrategia. Existen varias opciones tales como conducir su propio coche, tomando un taxi, una lanzadera del aeropuerto, un autobús de la ciudad, o un servicio de limusina. Para algunos aeropuertos, subterráneos y los helicópteros están también disponibles como un modo de transporte al aeropuerto. Cualquiera de estos modos de transporte recibirá un viajero en el aeropuerto, y se pueden utilizar indistintamente. El viajero debe elegir la estrategia basada en el equilibrio entre coste, comodidad y tiempo.

Lista de verificación 1. Identificar un algoritmo (es decir, un comportamiento) que el cliente prefiere el acceso a través de un punto de "FLEX". 2. Especifique la firma de ese algoritmo en una interfaz. 3. Enterrar los detalles de implementación de alternativas en las clases derivadas. 4. Los clientes del algoritmo par a sí mismos en la interfaz.

Reglas del pulgar Estrategia es como método de plantilla excepto en su granularidad. Es como estrategia del estado excepto en su intención. Estrategia permite cambiar las entrañas de un objeto. Decorador: permite cambiar la piel.

Strategy | 107

Estado, Estrategia, Puente (y en cierta medida el adaptador) tienen estructuras similares de solución. Todos ellos comparten elementos del "ASA/cuerpo' idioma. Difieren en su intención, es decir, resuelven problemas diferentes. La estrategia tiene dos implementaciones diferentes, la primera es como Estado. La diferencia está en los tiempos de enlace (Estrategia es un patrón de bind-una vez, mientras que el Estado es más dinámico). Los objetos suelen hacer una buena estrategia de contrapesos.

108 | Strategy

Método de plantilla La intención • Definir el esqueleto de un algoritmo en una operación, el aplazamiento de algunos

pasos para subclases de cliente. Método de plantilla permite que las subclases redefinan ciertos pasos de un algoritmo sin cambiar la estructura del algoritmo. • Clase base algoritmo declara "marcadores", y las clases derivadas implementan

los marcadores de posición.

Problema Dos diferentes componentes tienen similitudes significativas, pero no reflejan la reutilización de interfaz común o aplicación. Si un cambio común a ambos componentes se vuelve necesario, duplicar el esfuerzo debe ser gastado.

Discusión El diseñador de componentes decide qué pasos de un algoritmo son invariantes (o estándar), y que son de tipo Variant (o personalizables). Los pasos son invariantes implementado en una clase base abstracta, mientras que la variante pasos son dados una implementación predeterminada, o ninguna aplicación a todos. La variante pasos representan "ganchos" o "marcadores", que puede, o debe ser suministrado por el cliente del componente en una clase derivada concreta. El diseñador de componentes de los mandatos de los pasos necesarios de un algoritmo, y el orden de los pasos, pero permite que el componente cliente para ampliar o reemplazar algunos de estos pasos. Se utiliza el método plantilla prominentemente en marcos. Cada marco se implementa los trozos invariantes de una arquitectura del dominio, y define "marcadores" para todas las opciones de personalización del cliente o interesante. Al hacerlo, el marco se convierte en el "centro del universo", y el cliente personalizaciones son simplemente "la tercera roca desde el sol". Esta estructura de control invertido ha sido cariñosamente llamada "el principio de Hollywood" - "no nos llama, nos pondremos en contacto con usted".

Template Method | 109

Estructura

La aplicación del método es: plantilla_call _one step step_llamada , dos, y llame a paso_3. Paso_2 es un método de "gancho" - un marcador de posición. Es declarado en la clase base y, a continuación, define en clases derivadas. Marcos (grandes infraestructuras de reutilización) Método Usar plantilla mucho. Todo código reutilizable está definido en el marco de las clases base y, a continuación, los clientes del marco son libres de definir las personalizaciones mediante la creación de clases derivadas, según sea necesario.

Ejemplo La plantilla método define un esqueleto de un algoritmo en una operación, y se aplaza unos pasos en subclases. 110 | Template Method

Home Builders utilice el método plantilla al desarrollar una nueva subdivisión. Una subdivisión típica consta de un número limitado de los planos de planta con diferentes variantes disponibles para cada una de ellas. La variación es introducida en las etapas posteriores de la construcción para producir una gran variedad de modelos.

Lista de verificación 1. Examine el algoritmo, y decidir qué medidas son estándar y los pasos que son peculiares de cada una de las clases. 2. Definir una nueva clase base abstracta para acoger el "no nos llame, le llamaremos" marco. 3. Mover la carcasa del algoritmo (ahora llamado el "template method") y la definición de todos los pasos estándar para la nueva clase base. 4. Definir un marcador o un "gancho" método de la clase base para cada paso que requiere muchas implementaciones diferentes. Este método puede alojar una implementación predeterminada - o - puede ser definida como abstracta (Java) o virtual pura (C++). 5. Invoque el método(s) de gancho desde el método de la plantilla.

Template Method | 111

6. Cada una de las clases existentes declara un "es-relación" a la nueva clase base abstracta. 7. Quitar de las clases existentes de todos los detalles de implementación que se han trasladado a la clase base. 8. Los únicos detalles que permanecerán en las clases existentes será la aplicación detalles peculiares de cada clase derivada.

Reglas del pulgar Estrategia es como método de plantilla excepto en su granularidad.

Método de plantilla utiliza la herencia para variar parte de un algoritmo. Estrategia utiliza delegación para variar todo el algoritmo.

Estrategia modifica la lógica de los objetos individuales. Método plantilla modifica la lógica de toda una clase.

Método de fábrica es una especialización del método de plantilla.

112 | Template Method

Visitante La intención • Representan una operación a realizar sobre los elementos de una estructura de objeto.

Visitante le permite definir una nueva operación sin cambiar las clases de los elementos sobre los que opera. • La técnica clásica para recuperar información de tipo. • Hacer lo correcto basado en el tipo de dos objetos. • Distribución doble

Problema Muchas y distintas operaciones independientes deben llevarse a cabo en el nodo objetos en un agregado heterogéneo estructura. Desea evitar "contaminar" el nodo clases con estas operaciones. Y, usted no quiere tener que consultar el tipo de cada nodo y convertir el puntero al tipo correcto antes de realizar la operación deseada.

Discusión El propósito principal del visitante es abstraer la funcionalidad que puede aplicarse a una jerarquía de agregados de "elemento" de objetos. El método anima a diseñar clases de elemento ligero - porque la funcionalidad de procesamiento se elimina de su lista de responsabilidades. La nueva funcionalidad se pueden agregar fácilmente a la jerarquía de herencia original mediante la creación de una nueva subclase de visitante. Visitante implementa la "distribución doble". OO mensajes rutinariamente manifiestan "solo envío" - la operación que se ejecuta depende de: el nombre de la solicitud y el tipo de receptor. En la sección "distribución doble", la operación ejecutada depende de: el nombre de la solicitud y el tipo de los dos receptores (el tipo de visitante y el tipo de elemento que visitas). La aplicación procede como sigue. Crear una jerarquía de clases de visitantes que define un método puro visita virtual en la clase base abstracta para cada clase derivada concreta en la jerarquía de nodos agregados.

Visitor | 113

Cada visita método acepta un único argumento: un puntero o una referencia a una clase derivada del elemento original. Cada operación para ser admitido es modelada con una clase derivada concreta de la jerarquía del visitante. La visita los métodos declarados en la clase base de visitante ya están definidos en cada subclase derivada asignando el "tipo de consulta y yeso" el código en la implementación original a la correspondiente visita método sobrecargado. Agregar un solo acepta el método virtual puro a la clase base de la jerarquía de elementos. Aceptar está definido para recibir un solo argumento -un puntero o una referencia a la clase base abstracta de la jerarquía del visitante. Cada clase derivada concreta de la jerarquía de elementos implementa el método de aceptar simplemente llamando a la visita en el método de instancia derivada concreta de la jerarquía del visitante que se aprobara, pasando su puntero "this" como único argumento. Todo por "elementos" y "visitantes" está ahora configurado. Cuando el cliente necesita una operación que se realiza, se crea una instancia del objeto visitante, llama al método aceptar en cada objeto Element, y pasa el objeto de visitante. Aceptar el método

provoca que el flujo de control para encontrar el elemento correcto subclase. Luego, cuando la visita método es invocado, el flujo de control se dirigieron a la subclase visitante correcto. Aceptar el envío plus equivale al doble de visitas despacho. El patrón Visitor permite agregar nuevas operaciones (o utilidades) Fácil - simplemente añadir una nueva clase derivada del visitante. Pero, si las subclases en la jerarquía de nodos agregados no son estables, manteniendo el visitante subclases en sync requiere una cantidad prohibitiva de esfuerzo. Una reconocida objeción al patrón Visitor es que representa una regresión a la descomposición funcional - separar los algoritmos de estructuras de datos. Aunque esta es una interpretación legítima, quizá una mejor perspectiva/razón es la meta de promover el comportamiento no-tradicionales al estado del objeto completo.

Estructura La jerarquía de elementos está instrumentada con un "método universal adaptador". La aplicación de aceptar en cada clase derivada de elemento

114 | Visitor

Es siempre el mismo. Pero, no se puede mover a la clase base y elemento heredado por todas las clases derivadas porque una referencia a ello en la clase de elemento se asigna siempre al tipo base del elemento.

Cuando el método se llama firstDispatch polimórficos en un primer objeto abstracto, el tipo concreto de ese objeto es "recuperado". Cuando el método se llama secondDispatch polimórficos en un segundo objeto abstracto, su tipo concreto es "recuperado". La funcionalidad de la aplicación apropiada para este par de tipos puede ahora ser ejercida.

Visitor | 115

Ejemplo El patrón Visitor representa una operación que se realiza sobre los elementos de una estructura de objeto sin cambiar las clases en las que opera. Este patrón puede ser observada en el funcionamiento de una empresa de taxis. Cuando una persona llama a una empresa de taxis (aceptación de un visitante), la compañía distribuye una cabina para el cliente. Al entrar en el taxi, el cliente o visitante, ya no está en control de su propio transporte, el taxi (conductor).

116 | Visitor

Lista de verificación 1. Confirme que la jerarquía actual (conocido como la jerarquía de elementos) será estable y que la interfaz pública de estas clases es suficiente para el acceso al visitante las clases se requieren. Si estas condiciones no se cumplen, entonces el patrón Visitor no es un buen partido. 2. Crear una clase base de visitante con una visita(ElementXxx) Método para cada elemento tipo derivado. 3. Agregar un accept(Visitante) Método para la jerarquía de elementos. La aplicación en cada elemento clase derivada es siempre el mismo: aceptar(v) visitante { v.visita(this); }. Debido a las dependencias cíclicas, la declaración del elemento y clases de visitante tendrá que estar intercalada. 4. La jerarquía de elementos está acoplado únicamente a la clase base de visitante, pero la visitante jerarquía está acoplado a cada elemento de la clase derivada. Si la estabilidad de la jerarquía de elementos es baja, y la estabilidad de la jerarquía del visitante es alto; considerar la permutación de las 'funciones' de las dos jerarquías.

Visitor | 117

5. Crear una clase derivada de visitante para cada "operación" a realizarse en objetos Element. Las implementaciones de la visita dependerá de la interfaz pública del elemento. 6. El cliente crea objetos de visitante y pasa cada elemento objetos llamando aceptar.

Reglas del pulgar El árbol de sintaxis abstracta de intérprete es un compuesto (por lo tanto iterador y visitante también son aplicables). Iterador puede atravesar un compuesto. Visitante puede aplicar una operación sobre un compuesto. El patrón Visitor es como un patrón de comando más potentes debido a que el visitante podrá iniciar lo que sea apropiado para el tipo de objeto que encuentra. El patrón Visitor es la clásica técnica para recuperar la información de tipo sin recurrir a figuras dinámicas.

118 | Visitor

Acerca del Autor Mi nombre es Alejandro Shvets. He estado trabajando con software por 12 años, incluyendo 7 años de experiencia comercial. En la Universidad de Melbourne, se licenció en ingeniería de software y psicología, y obtuvo el doctorado con una tesis sobre "la reutilización para el diseño en Ingeniería de Software y Human-Computer Interaction." Yo vivo en Kiev y consultar sobre cuestiones de desarrollo de software en el sector de la banca y la sanidad. Usted puede encontrar mis datos de contacto a mi página de inicio (http://sourcemaking.com)

About The Author | 119