BREVE SISNTESIS DE LOS PATRONES DE DISEÑO

1. DESARROLLO DE APLICACIONES II
ITI JOSÉ LUIS CARRANZA FLORES
CARLOS ALBERTO DÍAZ NAVARRO
701 DESPRESURIZADO

2. Patrones de Diseño.
“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir
después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser
usada más de un millón de veces sin hacerlo siquiera dos veces de la misma forma” –
Christopher Alexander.
“El lenguaje de patrones brinda a todo el que lo utilice el poder de crear una infinita variedad de
construcciones nuevas y únicas, de la misma forma que su lenguaje común le brinda el poder
de crear una infinita variedad de oraciones." - Christopher Alexander.
I. INTRODUCCIÓN.
Conceptos básicos
Patrón de diseño: Base para la búsqueda de soluciones a problemas comunes en el desarrollo de
software [...] (wikipedia)
Para que una solución sea considerada un patrón debe poseer ciertas características:
• Efectivo resolviendo problemas similares en ocasiones anteriores.
• Reutilizable: aplicable a diferentes problemas de diseño en distintas circunstancias.
Los patrones son una disciplina de resolución de problemas reciente en la ingeniería del software que
ha emergido en mayor medida de la comunidad de orientación a objetos, aunque pueden ser aplicados
en cualquier ámbito de la informática y las ciencias en general. Los patrones tienen raíces en muchas
áreas, incluyendo la literate-programming y más notablemente en el trabajo de Christopher Alexander
en Planeamiento Urbanístico y Arquitectura Civil.
En el libro “The Timeless Way of Building” [Alexander79] (obra de referencia donde se plantea por
primera vez la teoría de los patrones aplicada a la Arquitectura Civil y Urbanismo), el Arquitecto
Christopher Alexander define al patrón en la siguiente manera:
“Cada patrón es una regla de 3 partes, que expresa una relación entre un contexto, un problema y una
solución. Como un elemento en el mundo, cada patrón es una relación entre un contexto, un sistema
de fuerzas que ocurren repetidamente en ese contexto y una configuración espacial que permite que
esas fuerzas se resuelvan entre sí.”
“Como elemento de un lenguaje, un patrón es una instrucción que muestra como puede ser usada esta
configuración espacial una y otra vez para resolver el sistema de fuerzas, siempre que el contexto lo
haga relevante.”
• ¿Qué es un patrón de diseño?”
“Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, para describir
después el núcleo de la solución a ese problema, de tal manera que esa solución pueda ser usada más
de un millón de veces sin hacerlo ni siquiera dos veces de la misma forma.”
Debemos tener en mente en todo momento al utilizar patrones:
o Los patrones son un punto de partida, no un destino.
o Los modelos no están bien o mal, sino que son más o menos útiles.

3. Patrones de Diseño.
II. DESARROLLO.
Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de
software.
En otras palabras, brindan una solución ya probada y documentada a problemas de desarrollo de
software que están sujetos a contextos similares. Debemos tener presente los siguientes elementos de
un patrón: su nombre, el problema (cuando aplicar un patrón), la solución (descripción abstracta del
problema) y las consecuencias (costos y beneficios) y se clasifican como se muestra a continuación:
• Patrones Creacionales: Inicialización y configuración de objetos.
o Fábrica Abstracta (Abstract Factory)
El problema a solucionar por este patrón es el de crear diferentes familias de objetos, como
por ejemplo la creación de interfaces gráficas de distintos tipos (ventana, menú, botón,
etc.).
Proporciona una interfaz para crear familias de objetos o que dependen entre sí, sin
especificar sus clases concretas
o Método de Fabricación (Factory Method)
Define una interfaz para crear un objeto.
Parte del principio de que las subclases determinan la clase a implementar.
o Prototipado (Prototype)
Se basa en la clonación de ejemplares copiándolos de un prototipo.
o Instancia Unica (Singleton)
Restringe la instanciación de una clase o valor de un tipo a un solo objeto y garantiza que
una clase solo tenga una instancia
o Constructor (Builder)
Separa la construcción de un objeto de su representación.
o MVC (Model View Controler)
Este patrón plantea la separación del problema en tres capas: la capa model, que representa
la realidad; la capa controler , que conoce los métodos y atributos del modelo, recibe y
realiza lo que el usuario quiere hacer; y la capa vista, que muestra un aspecto del modelo
y es utilizada por la capa anterior para interaccionar con el usuario.
• Patrones Estructurales: Se ocupan de cómo se combinan las clases y los objetos para formar
estructuras más grandes - Los patrones estructurales de clases hacen uso de la herencia para
componer interfaces o implementaciones.
o Adaptador (Adapter)
Convierte una interfaz en otra.
o Puente (Bridge)
Desacopla una abstracción de su implementación permitiendo modificarlas
independientemente.
o Objeto Compuesto (Composite)
Utilizado para construir objetos complejos a partir de otros más simples, utilizando para ello
la composición recursiva y una estructura de árbol.
o Envoltorio (Decorator)
Permite añadir dinámicamente funcionalidad a una clase existente, evitando heredar
sucesivas clases para incorporar la nueva funcionalidad.
o Fachada (Facade)
Permite simplificar la interfaz para un subsistema.

4. Patrones de Diseño.
o Peso Ligero (Flyweight)
Elimina la redundancia o la reduce cuando tenemos gran cantidad de objetos con
información idéntica.
o Apoderado (Proxy)
Un objeto se aproxima a otro.
• Patrones de Comportamiento: Tienen que ver con algoritmos y con la asignación de
responsabilidades a objetos. Describen no solo patrones de clases y objetos, sino también
patrones de comunicación entre ellos Más que describir objetos o clases, describen la
comunicación entre ellos.
o Cadena de responsabilidad (Chain of responsibility)
La base es permitir que más de un objeto tenga la posibilidad de atender una petición.
o Orden (Command)
Encapsula una petición como un objeto dando la posibilidad de “deshacer” la petición.
o Intérprete (Interpreter)
Intérprete de lenguaje para una gramática simple y sencilla.
o Iterador (Iterator)
Define una interfaz que declara los métodos necesarios para acceder secuencialmente a una
colección de objetos sin exponer su estructura interna.
o Mediador (Mediator)
Coordina las relaciones entre sus asociados. Permite la interacción de varios objetos, sin
generar acoples fuertes en esas relaciones.
o Recuerdo (Memento)
Almacena el estado de un objeto y lo restaura posteriormente.
o Observador (Observer)
Notificaciones de cambios de estado de un objeto.
Al utilizarlos hemos de tener
bien claro qué patrón utilizar
en cada caso: si necesitamos
realizarle más que unos
cambios mínimos puede ser
señal de que no sea el más
adecuado en dichas
circunstancias.
Otro concepto del que se
puede oír hablar es el de
anti-patrones, que hace
referencia a los errores que
comúnmente suelen ocurrir
al intentar solucionar
problemas conocidos.
No es necesario memorizar
cómo funcionan todos los
patrones, pero sí es
importante saber de su
existencia para así recurrir a
ellos en caso necesario.

5. Patrones de Diseño.
III. CONCLUSIÓN.
VENTAJAS DESVENTAJAS
Los patrones pretenden:
Proporcionar catálogos de elementos reusables
en el diseño de sistemas software.
Evitar la reiteración en la búsqueda de soluciones
a problemas ya conocidos y solucionados
anteriormente.
Formalizar un vocabulario común entre
diseñadores.
Estandarizar el modo en que se realiza el diseño.
Facilitar el aprendizaje de las nuevas
generaciones de diseñadores condensando
conocimiento existente.
Los patrones NO pretenden
Imponer ciertas alternativas de diseño frente a
otras.
Eliminar la creatividad inherente al proceso de
diseño.
No es obligatorio utilizar los patrones.
Es aconsejable en el caso de tener el mismo
problema o similar que soluciona el patrón.
Abusar o forzar el uso de los patrones puede ser
un error.
IV. BIBLIOGRAFÍA.
• Patrones de Diseño - Design Patterns (Elements of Reusable Object-Oriented Software),
por Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.
• Abstract Factory Pattern in VB .Net, por Rajesh V. S.
http://www.vbdotnetheaven.com/Code/Jun2003/2014.asp .
• Implementing the Command Pattern in .Net
http://blogs.vbcity.com/jspano/articles/198.aspx .
• Implementing the Visitor Design Pattern In .Net,
http://blogs.vbcity.com/jspano/articles/199.aspx .