ALGUNOS PATRONES DE DISEÑO CLÁSICOS
Hillside.net - Design Patterns Book - DP Book
Lo mismo que el post anterior, pero sobre algunos patrones de diseño del GoF:
* Prototype: otra manera de creación de objetos, pero utilizando un prototipo como medio de creación de instancias. La propia clase tiene un método "clone" que implementa un deep copy. La utilidad de Prototype es sobre todo para evitar la proliferación de estructuras paralelas, como ocurre con el Factory Method, y es muy importante para el tema de instancias cargadas dinámicamente: el usuario no se entera de con qué subclase concreta está trabajando. De todas formas, me vendría bien un ejemplo más claro.
* Bridge: desacoplamiento "físico" entre la abstracción y la implementación en dos clases diferentes. Esta idea es la que utilizamos en la implementación de drivers, la que nos permite crear las diferentes capas de una aplicación.
* Decorator: adición dinámica de nuevas responsabilidades a un objeto. Para ello se utiliza una jerarquía de objetos que encapsulan los objetos a modificar, manteniendo su interfaz pero añadiendo -por "arriba" o por "abajo"- su funcionalidad. El planteamiento de este patrón es la modificación de partes visibles o externas del objeto. Para cambiar su comportamiento interno es más útil el patrón Strategy o State.
* Flyweight: objetos muy repetitivos que sólo se almacenan una vez -como los caracteres en un procesador de textos-. La información intrínseca -en este caso el ASCII code- se almacena en el objeto carácter, mientras que la información extrínseca -el contexto del carácter en cada una de sus ocurrencias, como tamaño, fuente, ...- tiene que ser conocida en algún otro sitio. Esto permite que un documento no crezca demasiado, pues el acceso a los caracteres se realiza mediante referencia. Si un documento no cambia mucho de fuente y tamaño, el tratamiento será sencillo.
* Chain of Responsibility: desacoplamiento entre el cliente y el servidor mediante una serie de objetos que se van encargando de partes de la petición, o se van pasando hasta que alguien puede responder adecuadamente (como el DNS). El concepto es el de "burocracia".
* Interpreter: es la creación de un autómata, no es nada más, donde cada clase tiene un método de interpretación con un argumento de contexto -para saber dónde está-, y que puede realizar operaciones de comprobación de la gramática. El árbol en sí suele ser un composite. Es válido para gramáticas sencillas -es lo que utilicé en el SGRT, sin saberlo ;) -.
* Mediator: un "manager" que se encarga de gestionar las interacciones de un conjunto de objetos, para así evitar un excesivo acoplamiento entre sí. Se puede implementar también como un observer, de manera que los objetos envían notificaciones al mediador cuando cambian de estado.
* Memento: patrón que permite capturar y externalizar el estado interno de un objeto, de manera que pueda ser restaurado a ese mismo estado más tarde. Aunque comprendo la idea, un ejemplo de cómo se utiliza exactamente el patrón no vendría mal.
* Strategy: definición de una familia de algoritmos para hacerlos intercambiables.
* Template Method: la superclase deja la implementación de partes del algoritmo como métodos redefinibles por las subclases, de manera que se puedan modificar fácilmente. Sigue el "principio de Hollywood: no nos llames, te llamaremos nosotros", refiriéndose a que sea el padre quien realice las operaciones.
* Visitor: cuando las clases de una jerarquía de clases invocan diferentes métodos dispares entre sí, quizá es mejor crear una jerarquía complementaria para cada tipo de método (métodos parecidos que se invocan desde diferentes subclases), de manera que se estructure todo mejor. El visitor permite que las operaciones relacionadas estén juntas en una misma clase, de manera que las clases de la primera estructura que lo necesiten, accederán como "visitantes" a esas operaciones.
Hillside.net - Design Patterns Book - DP Book
Lo mismo que el post anterior, pero sobre algunos patrones de diseño del GoF:
* Prototype: otra manera de creación de objetos, pero utilizando un prototipo como medio de creación de instancias. La propia clase tiene un método "clone" que implementa un deep copy. La utilidad de Prototype es sobre todo para evitar la proliferación de estructuras paralelas, como ocurre con el Factory Method, y es muy importante para el tema de instancias cargadas dinámicamente: el usuario no se entera de con qué subclase concreta está trabajando. De todas formas, me vendría bien un ejemplo más claro.
* Bridge: desacoplamiento "físico" entre la abstracción y la implementación en dos clases diferentes. Esta idea es la que utilizamos en la implementación de drivers, la que nos permite crear las diferentes capas de una aplicación.
* Decorator: adición dinámica de nuevas responsabilidades a un objeto. Para ello se utiliza una jerarquía de objetos que encapsulan los objetos a modificar, manteniendo su interfaz pero añadiendo -por "arriba" o por "abajo"- su funcionalidad. El planteamiento de este patrón es la modificación de partes visibles o externas del objeto. Para cambiar su comportamiento interno es más útil el patrón Strategy o State.
* Flyweight: objetos muy repetitivos que sólo se almacenan una vez -como los caracteres en un procesador de textos-. La información intrínseca -en este caso el ASCII code- se almacena en el objeto carácter, mientras que la información extrínseca -el contexto del carácter en cada una de sus ocurrencias, como tamaño, fuente, ...- tiene que ser conocida en algún otro sitio. Esto permite que un documento no crezca demasiado, pues el acceso a los caracteres se realiza mediante referencia. Si un documento no cambia mucho de fuente y tamaño, el tratamiento será sencillo.
* Chain of Responsibility: desacoplamiento entre el cliente y el servidor mediante una serie de objetos que se van encargando de partes de la petición, o se van pasando hasta que alguien puede responder adecuadamente (como el DNS). El concepto es el de "burocracia".
* Interpreter: es la creación de un autómata, no es nada más, donde cada clase tiene un método de interpretación con un argumento de contexto -para saber dónde está-, y que puede realizar operaciones de comprobación de la gramática. El árbol en sí suele ser un composite. Es válido para gramáticas sencillas -es lo que utilicé en el SGRT, sin saberlo ;) -.
* Mediator: un "manager" que se encarga de gestionar las interacciones de un conjunto de objetos, para así evitar un excesivo acoplamiento entre sí. Se puede implementar también como un observer, de manera que los objetos envían notificaciones al mediador cuando cambian de estado.
* Memento: patrón que permite capturar y externalizar el estado interno de un objeto, de manera que pueda ser restaurado a ese mismo estado más tarde. Aunque comprendo la idea, un ejemplo de cómo se utiliza exactamente el patrón no vendría mal.
* Strategy: definición de una familia de algoritmos para hacerlos intercambiables.
* Template Method: la superclase deja la implementación de partes del algoritmo como métodos redefinibles por las subclases, de manera que se puedan modificar fácilmente. Sigue el "principio de Hollywood: no nos llames, te llamaremos nosotros", refiriéndose a que sea el padre quien realice las operaciones.
* Visitor: cuando las clases de una jerarquía de clases invocan diferentes métodos dispares entre sí, quizá es mejor crear una jerarquía complementaria para cada tipo de método (métodos parecidos que se invocan desde diferentes subclases), de manera que se estructure todo mejor. El visitor permite que las operaciones relacionadas estén juntas en una misma clase, de manera que las clases de la primera estructura que lo necesiten, accederán como "visitantes" a esas operaciones.
Comments