Patrones de Diseño
Profesor de Ingenieria de Software
y de comportamiento.
lean los mensajes, respondan no agreguen nuevas entradas
ngallia
y que se presentan en situaciones particulares del diseño, con el fin
de proponer soluciones a ellas. Por lo tanto, los patrones de diseño
son soluciones exitosas a problemas comunes. Existen muchas formas de
implementar patrones de diseño. Los detalles de las implementaciones
son llamadas estrategias.
Un patrón de diseño es una abstracción de una solución en un nivel
alto. Los patrones solucionan problemas que existen en muchos niveles
de abstracción. Hay patrones que abarcan las distintas etapas del
desarrollo; desde el análisis hasta el diseño y desde la arquitectura
hasta la implementación.
Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides (Gang of
Four) escribieron un libro en el año 1994 llamado "Design Patterns:
Elements of Reusable Object Oriented Sofware", donde recopilaron y
documentaron 23 patrones de diseño aplicados usualmente por expertos
diseñadores de software orientado a objetos.
Clasificaron los patrones en 3 grandes categorías basadas en su
PROPÓSITO: creacionales, estructurales y de comportamiento.
Creacionales: Patrones creacionales tratan con las formas de crear
instancias de objetos. El objetivo de estos patrones es de abstraer el
proceso de instanciación y ocultar los detalles de cómo los objetos
son creados o inicializados.
Estructurales: Los patrones estructurales describen como las clases y
objetos pueden ser combinados para formar grandes estructuras y
proporcionar nuevas funcionalidades. Estos objetos adicionados pueden
ser incluso objetos simples u objetos compuestos.
Comportamiento: Los patrones de comportamiento nos ayudan a definir la
comunicación e iteración entre los objetos de un sistema. El propósito
de este patrón es reducir el acoplamiento entre los objetos.
En el segundo nivel, ellos clasificaron los patrones en 2 ámbitos:
Clases y objetos. Es así que, tenemos 6 tipos de patrones:
Creacional de la Clase
Los patrones creacionales de Clases usan la herencia como un mecanismo
para lograr la instanciación de la Clase. Por ejemplo el Factory
Method
Creacional del objeto
Los patrones creacionales de objetos son más escalables y dinámicos
comparados de los patrones creacionales de Clases. Por ejemplo la
Abstract Factory y el patrón Singleton.
Estructural de la Clase
Los patrones estructurales de Clases usan la herencia para
proporcionar interfaces más útiles combinando la funcionalidad de
múltiples Clases. Por ejemplo el patrón Adapter (Clase).
Estructural de Objetos
Los patrones estructurales de objetos crean objetos complejos
agregando objetos individuales para construir grandes estructuras. La
composición de l patrón estructural del objeto puede ser cambiado en
tiempo de ejecución, el cual nos da flexibilidad adicional sobre los
patrones estructurales de Clases. Por ejemplo el Adapter (Objeto),
Facade, Bridge, Composite.
Comportamiento de Clase
Los patrones de comportamiento de Clases usan la herencia para
distribuir el comportamiento entre Clases. Por ejemplo Interpreter.
Comportamiento de Objeto
Los patrones de comportamiento de objetos nos permite analizar los
patrones de comunicación entre objetos interconectados, como objetos
incluidos en un objeto complejo. Ejemplo Iterator, Observer, Visitor.
Mauricio Jost
Agregando a lo que dijo mi compañero:
"Una arquitectura orientada a objetos bien estructurada está llena de patrones. La calidad de un sistema orientado a objetos se mide por la atención que los diseñadores han prestado a las colaboraciones entre sus objetos. Los patrones conducen a arquitecturas más pequeñas, más simples y más comprensibles". (Grady Booch)
Los patrones de diseño son los siguientes (segun el criterio de comportamiento):
| Ambito |
Creacion | Estructural | |
| Clase | Método de Fabricación | Adaptador (clases) | De conducta Interprete Plantilla |
| Objeto | Fábrica, Constructor, Prototipo, Singleton | Adaptador (objetos), Puente, Composición, Decorador, Fachada, Flyweight | Cadena de Responsabilidad, Comando (orden), Iterador,
Intermediario, Observador, Estado, Estrategia, Visitante, Memoria |
Los patrones resaltados son los que hemos visto en clases, que corresponden a la clasificacion de patrones creacionales de objetos. Notese que tambien hay patrones para la creacion de clases.El patron decorator es el que vamos a ver. Este tiene que ver, como se ve en la tabla, con una forma de estructurar los objetos, a los efectos de flexibilizar al maximo su utilizacion, añadiendo colecciones a su uso.
En general los patrones de diseño son "descripciones de clases cuyas instancias colaboran entre sí". Cada patrón es adecuado para ser adaptado a un cierto tipo de problema. Para describir un caso debemos necesariomente especificar:
- Nombre
- Propósito o finalidad
- Sinónimos (otros nombres por los que puede ser conocido)
- Problema al que es aplicable
- Estructura (diagrama de clases)
- Participantes (responsabilidad de cada clase)
- Colaboraciones (diagrama de interacciones)
- Implementación (consejos, notas y ejemplos)
- Otros patrones con los que está relacionado
Un interesante ejemplo de la implementacion de varios patrones de diseño:
http://mit.ocw.universia.net/6.170/6.170/f01/pdf/lecture-12.pdf
Fer
Son soluciones simples y elegantes a problemas específicos y comunes
del diseño orientado a objetos. Son soluciones basadas en la
experiencia y que se ha demostrado que funcionan.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay
problemas que se repiten o que son análogos, es decir, que responden a
un cierto patrón. Sería deseable tener una colección de dichos
patrones con las soluciones más óptimas para cada caso.
Los patrones de diseño no son fáciles de entender, pero una vez
entendido su funcionamiento, los diseños serán mucho más flexibles,
modulares y reutilizables. Han revolucionado el diseño orientado a
objetos y todo buen arquitecto de software debería conocerlos.
A continuación una lista con los patrones de diseño a objetos más
habituales publicados en el libro "Design Patterns", escrito por los
que comúnmente se conoce como GoF (gang of four, "pandilla de los
cuatro").
Patrones de creación
· Abstract Factory. Proporciona una interfaz para crear familias de
objetos o que dependen entre sí, sin especificar sus clases
concretas.
· Builder. Separa la construcción de un objeto complejo de su
representación, de forma que el mismo proceso de construcción pueda
crear diferentes representaciones.
· Factory Method. Define una interfaz para crear un objeto, pero deja
que sean las subclases quienes decidan qué clase instanciar. Permite
que una clase delegue en sus subclases la creación de objetos.
· Prototype. Especifica los tipos de objetos a crear por medio de una
instancia prototípica, y crear nuevos objetos copiando este
prototipo.
· Singleton. Garantiza que una clase sólo tenga una instancia, y
proporciona un punto de acceso global a ella.
Patrones estructurales
· Adapter. Convierte la interfaz de una clase en otra distinta que es
la que esperan los clientes. Permiten que cooperen clases que de otra
manera no podrían por tener interfaces incompatibles.
· Bridge. Desvincula una abstracción de su implementación, de manera
que ambas puedan variar de forma independiente.
· Composite. Combina objetos en estructuras de árbol para representar
jerarquías de parte-todo. Permite que los clientes traten de manera
uniforme a los objetos individuales y a los compuestos.
· Decorator. Añade dinámicamente nuevas responsabilidades a un objeto,
proporcionando una alternativa flexible a la herencia para extender la
funcionalidad.
· Facade. Proporciona una interfaz unificada para un conjunto de
interfaces de un subsistema. Define una interfaz de alto nivel que
hace que el subsistema se más fácil de usar.
· Flyweight. Usa el compartimiento para permitir un gran número de
objetos de grano fino de forma eficiente.
· Proxy. Proporciona un sustituto o representante de otro objeto para
controlar el acceso a éste.
Patrones de comportamiento
· Chain of Responsibility. Evita acoplar el emisor de una petición a
su receptor, al dar a más de un objeto la posibilidad de responder a
la petición. Crea una cadena con los objetos receptores y pasa la
petición a través de la cadena hasta que esta sea tratada por algún
objeto.
· Command. Encapsula una petición en un objeto, permitiendo así
parametrizar a los clientes con distintas peticiones, encolar o llevar
un registro de las peticiones y poder deshacer la operaciones.
· Interpreter. Dado un lenguaje, define una representación de su
gramática junto con un intérprete que usa dicha representación para
interpretar las sentencias del lenguaje.
· Iterator. Proporciona un modo de acceder secuencialmente a los
elementos de un objeto agregado sin exponer su representación
interna.
· Mediator. Define un objeto que encapsula cómo interactúan un
conjunto de objetos. Promueve un bajo acoplamiento al evitar que los
objetos se refieran unos a otros explícitamente, y permite variar la
interacción entre ellos de forma independiente.
· Memento. Representa y externaliza el estado interno de un objeto sin
violar la encapsulación, de forma que éste puede volver a dicho estado
más tarde.
· Observer. Define una dependencia de uno-a-muchos entre objetos, de
forma que cuando un objeto cambia de estado se notifica y actualizan
automáticamente todos los objetos.
· State. Permite que un objeto modifique su comportamiento cada vez
que cambia su estado interno. Parecerá que cambia la clase del
objeto.
· Strategy. Define una familia de algoritmos, encapsula uno de ellos y
los hace intercambiables. Permite que un algoritmo varíe
independientemente de los clientes que lo usan.
· Template Method. Define en una operación el esqueleto de un
algoritmo, delegando en las subclases algunos de sus pasos. Permite
que las subclases redefinan ciertos pasos del algoritmo sin cambiar su
estructura.
· Visitor. Representa una operación sobre los elementos de una
estructura de objetos. Permite definir una nueva operación sin cambiar
las clases de los elementos sobre los que opera.
On 2 mayo, 07:26, Profesor de Ingenieria de Software
Guillermo Veneranda
La pagina tiene un link a la version original de Sun en Ingles
http://www.programacion.net/java/tutorial/patrones/
Gastón Medina
En la programación orientada a objetos resulta complicado descomponer el sistema en objetos (encapsulación, granularidad, dependencias, flexibilidad, reusabilidad, etc.), los patrones de diseño nos permitirán identificar a los objetos apropiados de una manera mucho más sencilla.
· Patrones de creación: para creación de instancias.
· Patrones estructurales: relaciones entre clases, combinación y formación de estructuras mayores.
· Patrones de comportamiento: interacción y cooperación entre clases.
Patrones de creación
Los patrones de cración abstraen la forma en la que se crean los objetos, permitiendo tratar las clases a crear de forma genérica dejando para más tarde la decisión de qué clases crear o cómo crearlas.
Según donde se tome dicha decisión podemas clasificar a los patrones de creación en patrones de creación de clase (la decisión se toma en los constructores de las clases y usan la herencia para determinar la creación de las instancias) y patrones de creación de objeto (se modifica la clase desde el objeto).
Patrones estructurales
Tratan de conseguir que cambios en los requisitos de la aplicación no ocasionen cambios en las relaciones entre los objetos. Lo fundamental son las relaciones de uso entre los objetos, y, éstas están determinadas por las interfaces que soportan los objetos. Estudian como se relacionan los objetos en tiempo de ejecución. Sirven para diseñar las interconexiones entre los objetos.
Patrones de comportamiento
Los patrones de comportamiento estudian las relaciones entre llamadas entre los diferentes objetos, normalmente ligados con la dimensión temporal.
christian martinez
Los patrones de diseño describen un problema que ocurre repetidas
veces en algún contexto determinado de desarrollo de software, y
entregan una buena solución ya probada. Esto ayuda a diseñar
correctamente en menos tiempo, ayuda a construir problemas
reutilizables y extensibles, y facilita la documentación. Los patrones
te enseñan a aplicar de manera eficaz qué hacer con la herencia, el
polimorfismo, etc.
Un patrón de diseño es una descripción de clases y objetos
comunicándose entre sí, adaptada para resolver un problema de diseño
general en un contexto particular. Se tienen distintas
clasificaciones, ya sea el propósito, el ámbito, etc.
En este caso, la clasificación que nos interesa es la del propósito,
entre las que el patrón tiene que:
*crear objetos (PATRÓN DE CREACIÓN)
*componer objetos y/o clases (PATRÓN ESTRUCTURAL)
*hacer interactuar a las distintas clases y objetos (PATRÓN DE
COMPORTAMIENTO)
Los patrones de creación proporcionan ayuda a la hora de crear
objetos, principalmente cuando esta creación requiere tomar
decisiones. Esta toma de decisiones puede ser dinámica. Estos patrones
ayudan a estructurar y encapsular estas decisiones. En algunas
ocasiones existe más de un patrón que se puede aplicar a la misma
situación. En otras ocasiones se pueden combinar múltiples patrones
convenientemente. Un patrón de creación asociado a clases usa la
herencia para variar la clase que se instancia, mientras que un patrón
de creación asociado a objetos delegará la instanciación a otro
objeto.
Hay dos formas de clasificar los patrones de creación basándose en las
clases de objetos que se crean. Una es clasificar las clases que crean
los objetos (Factory Method), otra forma está relacionada con la
composición de objetos; definir un objeto que es responsable de
conocer las clases de los objetos producto, en esta característica se
apoyan los patrones Abstract Factory, Builder o Prototype. En muchas
ocasiones los patrones de creación compiten en su función. Por
ejemplo, hay casos donde Protoype y Abstract Factory puede utilizarse
indistintamente. En otras ocasiones Builder puede usar a los otros
patrones para implementar los componentes que construye.
Los patrones estructurales están relacionados con cómo las clases y
los objetos se combinan para dar lugar a estructuras más complejas.
Puede hacerse aquí la misma distinción que haciamos en los patrones de
creación y hablar de patrones estructurales asociados a clases
(Adapter) y asociados a objetos (Bridge, Composite, Decorator, Facade,
Flyweight, Proxy), los primeros utilizarán la herencia, los segundos
la composición.
Los patrones estructurales asociados con objetos describen formas de
componer los objetos para conseguir nueva funcionalidad. La
flexibilidad de la composición de objetos viene de la posibilidad de
cambiar la composición en tiempo de ejecución, lo que es imposible con
la composición estática de clases.
En general estos patrones de diseño están relacionados con algoritmos
y asignación de responsabilidades a los objetos. Los patrones de
comportamiento describen no sólamente patrones de objetos o clases
sino también patrones de comunicación entre ellos. Nuevamente se
pueden clasificar en función de que trabajen con clases (Template
Method, Interpreter) u objetos (Chain of Responsability, Command,
Iterator, Mediator, Memento, Observer, State, Strategy, Visitor).
La variación de la encapsulación es la base de muchos patrones de
comportamiento. Cuando un aspecto de un programa cambia
frecuentemente, estos patrones definen un objeto que encapsula dicho
aspecto. Los patrones definen una clase abstracta que describe la
encapsulación del objeto.
Javier Lusso
Los antipatrones se basan en la idea de que puede resultar más fácil detectar a priori fallos en el desarrollo del proyecto que elegir el camino correcto, o lo que es lo mismo, descartar las alternativas incorrectas nos puede ayudar a la elección de la mejor alternativa.
Los antipatrones se clasifican en antipatrones de desarrollo, de arquitectura de software y de gestión de proyectos.
-Antipatrones de desarrollo:
-The blob (clases gigantes)
-Lava flow (código muerto)
-Functional Decomposition (Diseño No Orientado a Objetos)
-Poltergeists (No se sabe lo que hacen algunas clases)
-Golden Hammer (Para un martillo todo son clavos)
-Spaghetti Code (Muchos if o switch)
-Cut & Paste programming (cortar y pegar código)
-Antipatrones de arquitectura de software:
-Stovepipe enterprise (Aislamiento en la empresa, Islas de Automatización o Empresa con sistemas parcheados). La causa suele estar en una falta de estrategia tecnológica en la empresa, falta de cooperación y comunicación entre departamentos y niveles, deficiencias en el conocimiento de la tecnología, etc.
-Stovepipe system (Legacy System, Sistema Heredado, Aislamiento entre sistemas o Sistema Parcheado)
-Vendor Lock-In (Arquitectura dependiente del producto, Amarrado por el vendedor, Esclavitud y Sumisión)
-Architecture by implication (Arquitectura Implícita). No se especifica la arquitectura del sistema o ignora alguno de sus apartados.
-Design by committee (Diseño por Comité, Navaja suiza, Chapa de Oro, Enfermedad de Estandarización) Se da cuando el proyecto se diseña a través de las reuniones de un comité demasiado numeroso o inexperto.
-Reinvent the wheel Se supone que se debe desarrollar desde cero, falta información y tecnología reusable entre proyectos
-Antipatrones de gestión de proyectos:
-Analysis paralysis. Ocurre cuando un equipo de analistas comienza una fase de análisis que sólo acaba cuando se cancela el proyecto.
-Death by planning
-Corncob (Personas problematicas)
-Irrational management
-Project mismanegement
Por último, les dejo 2 PDF que me parecieron muy interesantes que encontré en Internet.
kobain
Diseño:
La documentación de un patrón de diseño describe el contexto en el
cual un patrón es usado, las fuerzas dentro del contexto que el patrón
busca resolver, y la solución sugerida. No hay una forma única y
estándar de documentar patrones. En cambio, una variedad de diferentes
formatos han sido usados por diferentes autores de patrones. Sin
embargo, según Martin Fowler ciertas formas de patrones se han vuelto
más conocidas que otras, y consecuentemente puntos de partida comunes
para escribir nuevos patrones. Un ejemplo de un formato de
documentación comúnmente usadoa es el usado por Erich Gamma, Richard
Helm, Ralph Johnson and John Vlissides (colectivamente conocidos como
la "Gang of Four2") en su libro "Design Patterns" (Patrones de
Diseño). Contiene las siguientes secciones:
Nombre del patrón y Clasificación: Un nombre descriptivo y único que
ayuda a identificar y referirse al patrón.
Intención: Una descripción del objetivo detrás del patrón y la razón
para utilizarlo.
También conocido como: Otros nombres para el patrón.
Motivación (Fuerzas): Un escenario que consiste en un problema, y un
contexto en el cual el patrón puede ser usado.
Aplicabilidad: Situaciones en las cuales el patrón puede ser utilizado
(el contexto para el patrón).
Estructura: Una representación gráfica del patrón. Diagramas de Clases
y de Interacción pueden ser usados con este propósito.
Participantes: Un listado de las clases y objetos usados en el patrón
y sus funciones o roles en el diseño.
Colaboración: Una descripción de cómo las Clases y Objetos utilizados
en el patrón interactúan entre sí.
Consecuencias: Una descripción de los resultados, efectos secundarios,
y "trade offs" causados por el uso del patrón.
Implementación: Una descripción de una implementación del patrón; la
parte de la solución del patrón.
Ejemplo de Código: Una ilustración de cómo el patrón puede ser usado
en un lenguaje de programación (generalmente C++, Java o Smalltalk).
Usos Conocidos: Ejemplos de usos reales del patrón.
Patrones Relacionados: Otros patrones que tienen alguna relación con
el patrón; discusiónd de las diferencias entre el patrón y patrones
similares.
VERCELLONE, Juan José
Toni Abdala
encontré esta pagina muy buena sobre patrones tiene gráficos y todo
http://www.programacion.com/articulo/corej2ee_patterns/
conclusiones que encontré:
* "Los patrones de diseño son el esqueleto de las soluciones a problemas comunes en el desarrollo de software."
*Los patrones de diseño describen un problema que ocurre varias veces en algún contexto determinado del desarrollo de software y proporcionan una solución bien diseñada que ya ha sido probada .
*Creemos, sin embargo, que estos patrones sirven para ilustrar las ventajas de utilizar soluciones ya probadas.
y aqui unos codigos para ayudar
Método de Fabricación (Factory Method)
Parte del principio de que las subclases
determinan la clase a implementar.
public
class ConcreteCreator extends
Creator
{
protected Product
FactoryMethod()
{
return new ConcreteProduct();
}
}
public
interface Product{}
public
class ConcreteProduct implements
Product{}
public class
Client
{
public static void
main(String args[])
{
Creator UnCreator;
UnCreator = new
ConcreteCreator();
UnCreator.AnOperations();
}
}
Restringe la instanciación de una clase o valor de un tipo a un solo objeto.public sealed class Singleton
{
private static volatile Singleton instance;
private static object syncRoot = new Object();
private Singleton()
{
System.Windows.Forms.MessageBox.Show("Nuevo Singleton");
}
public static Singleton GetInstance
{
get
{
if (instance == null)
{
lock(syncRoot)
{
if (instance == null)
instance = new Singleton();
}
}
return instance;
}
}
}
Birocco Baudino Sergio
agregar sobre documentacion o sobre los diferentes patrones y su
clasificación,
por lo que opinare brevemente sobre lo ya expresado pero desde mi
punto de vista.
Segun lo que he leido de lo aqui expuesto y tambien de informacion de
internet
puedo decir que los patrones de diseño son basicamente soluciones
reutilizables, o sea,
si nosotros despues de experimentar problemas llegamos a soluciones
exitosas
tomamos en cuenta estas soluciones para algun otro caso similar, de
esta manera nos
ahorramos el tiempo de pensar como solucionar el problema ya que
aplicamos una
solucion exitosa anterior orientada al caso en cuestion, en cierta
forma los patrones
de diseño para desarrollo de software son soluciones documentadas a
las cuales los
programadores recurren o siguen al pie de la letra para ahorrar
tiempo, ganar
eficiencia y por supuesto lograr calidad en los trabajos gracias a
soluciones
estudiadas a lo largo de los años.
Basicamente esa es mi propia idea de lo que significa el termino
patrones de diseño,
y como ya dije antes no tiene sentido seguir agregando clasificaciones
pues creo que
lo que aqui importa es la idea de cada uno.
Si quieren ver algo sencillo sobre patrones y su clasificacion entren
aqui:
http://java.ciberaula.com/articulo/diseno_patrones_j2ee/
Jorge Racca
Patrones de diseño
Mis compañeros han sido lo
suficientemente claros a la hora de explicar esto de los patrones de diseño,
por lo que de mi parte, solo cabe dar una nueva definición que puede llegar a
ser útil para alguna persona que todavía en día no este correctamente informada
en lo que es, y en que se basan los patrones de diseño. Ademas he encontrado en la web unas filminas en formato power point que explican detalladamente lo que indico mas abajo.
En si, los patrones de diseño son soluciones simples y elegantes a problemas específicos y comunes del diseño orientado a objetos. Son soluciones basadas en la experiencia y que se ha demostrado que funcionan.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se repiten o que son análogos, es decir, que responden a un cierto patrón. Los patrones de diseño no son fáciles de entender, pero una vez entendido su funcionamiento, los diseños serán mucho más flexibles, modulares y reutilizables. Han revolucionado el diseño orientado a objetos y todo buen arquitecto de software debería conocerlos.
A continuación una lista con los patrones de diseño a objetos más habituales.
Gonzalo
"Los patrones de diseño son descripciones de objetos y clases
comunicándose, que son adaptadas para resolver un problema de diseño
general en un contexto particular". ("Design Patterns: Elements of
Reusable Object-Oriented Software" - Gamma, Helm, Jonson, Vlissides.)
El principal objetivo de los patrones de diseño es capturar buenas
prácticas que nos permitan mejorar la calidad del diseño de sistemas,
determinando objetos que soporten roles útiles en un contexto
específico, encapsulando complejidad, y haciéndolo más flexible.
* Porque son utiles los patrones de diseño.*
Los Patrones han demostrado ser una forma muy útil (exitosa) de
reutilizar diseño, ya que ellos no sólo nombran, abstraen e
identifican aspectos claves de estructuras comunes de diseño, sino que
generalmente son descritos en una forma específica documental,
haciendo su comprensión y aplicación fácil para el conjunto de
desarrolladores.
Podemos decir que los beneficios que un patrón produce pueden ser
medidos en varios sentidos:
- Contribuyen a reutilizar diseño, identificando aspectos claves de la
estructura de un diseño que puede ser aplicado en una gran cantidad de
situaciones. La importancia de la reutilización del diseño no es
despreciable, ya que ésta nos provee de numerosas ventajas: reduce los
esfuerzos de desarrollo y mantenimiento, mejora la seguridad,
eficiencia y consistencia de nuestros diseños, y nos proporciona un
considerable ahorro en la inversión.
- Mejoran (aumentan, elevan) la flexibilidad, modularidad y
extensibilidad, factores internos e íntimamente relacionados con la
calidad percibida por el usuario.
- Incrementan nuestro vocabulario de diseño, ayudándonos a diseñar
desde un mayor nivel de abstracción.
Matias Osca
Por haber llegado tarde a dar mi opinion sobre Patrones de Diseño, mis compañeros ya han agregado una inmensa cantidad de informacion sobre el tema. y con varios links. Me he tomado el trabajo de leerlos a todos y creo que la informacion es bastante completa.
He encontrado un PPT que resume en forma muy clara todo acerca de Patrones de Diseño y que son.
Está adjunto a este email.
--
< < Mathew > >
Charly
Me parece que ya hay demasiadas definiciones. Intentaré dar un ejemplo
un poco más concreto:
Patrón de Estado (State Pattern)
Le permite a un objeto alterar su comportamiento cuando
se modifica su estado interno.
Ejemplo:
Supongamos una conexión TCP que representa una conexión de RED.
El Objeto ConexionTCP puede estar en diferentes estados:
- Established
- Listening
- Closed
Cuando el Objeto ConexionTCP recibe una petición de otro objeto, va a
responder
de manera diferente dependiendo de su estado actual. Por ejemplo, el
efecto de
una petición Abierta depende si está en Estado Cerrado (Closed state)
o
en estado establecido (Established state). El Patrón
de Estado describe como
ConexionTCP puede mostrar diferente comportamiento en
cada caso.
La idea de este patrón es introducir una clase
abstracta que podemos llamar
TCPState que represente el estado actual de la Conexión de Red.
martincho
parar... y después describe la base de la solución a ese problema, de
una manera tal que uno puede utilizar esta solución un millón de
veces. Utilizándolos en nuestros diseños nos ahorraremos mucho
trabajo...
remarco este link q ya lo han citado: http://mit.ocw.universia.net/6.170/6.170/f01/pdf/lecture-12.pdf
sale muy bien ejemplicado cada patron...
On 2 mayo, 07:26, Profesor de Ingenieria de Software
<MCeboll...@gmail.com> wrote:
renz
· una técnica para flexibilizar el código haciéndolo satisfacer
ciertos criterios
· un proyecto o estructura de implementación que logra una finalidad
determinada
· un lenguaje de programación de alto nivel
· una manera más práctica de describir ciertos aspectos de la
organización de un programa
· conexiones entre componentes de programas
· la forma de un diagrama de objeto o de un modelo de objeto.
en sintesis son un conjunto de normas de como crear objetos
independizandolos de los constructores de los objetos.
se intenta hcer lo msa generico posible el codigo par independizar(lo
desacopla).
con esto me permite cambiar el funcionamiento de un objeto sin afectar
al sistema.
entre ellos estan:
PATRONES DE CREACION:
*singleton: patron en el cual tenemos una clase que tiene una sola
instancia objeto de tal manera que puede ser accedida desde cualquier
parte del sistema.
(un objeto con este patron se utiliza para meter toda la informacion
que se usa en general).
*factory builder: es una clase en donde dentro de la misma hay un
conunto de metodos en el cual cada uno de estos es responsable de la
creacion de un objeto o un conjunto de objetos de la misma naturaleza.
*clone o prototype: Crea nuevos objetos clonándolos de una instancia
ya existente.
*after factory: patron para escribir se implementa en la apariencia.
es para cambios grandes en los objetos.
*Builder (Constructor virtual): Abstrae el proceso de creación de un
objeto complejo, centralizando dicho proceso en un único punto
PATRONES ESTRUCTURALES:
Adapter: Adapta una interfaz para que pueda ser utilizada por una
clase que de otro modo no podría utilizarla.
Bridge : Desacopla una abstracción de su implementación.
Composite (Objeto compuesto): Permite tratar objetos compuestos como
si de uno simple se tratase.
Decorator : Añade funcionalidad a una clase dinámicamente.
Facade : Provee de una interfaz unificada simple para acceder a una
interfaz o grupo de interfaces de un subsistema.
Flyweight : Reduce la redundancia cuando gran cantidad de objetos
poseen idéntica información.
Proxy : Mantiene un representante de un objeto
PATRONES DE COMPORTAMIENTO:
Chain of Responsibility : Permite establecer la línea que deben llevar
los mensajes para que los objetos realicen la tarea indicada.
Command : Encapsula una operación en un objeto, permitiendo ejecutar
dicha operación sin necesidad de conocer el contenido de la misma.
Interpreter : Dado un lenguaje, define una gramática para dicho
lenguaje, así como las herramientas necesarias para interpretarlo.
Iterator : Permite realizar recorridos sobre objetos compuestos
independientemente de la implementación de estos.
Mediator : Define un objeto que coordine la comunicación entre objetos
de distintas clases, pero que funcionan como un conjunto.
Memento : Permite volver a estados anteriores del sistema.
Observer: Define una dependencia de uno-a-muchos entre objetos, de
forma que cuando un objeto cambie de estado se notifique y actualicen
automáticamente todos los objetos que dependen de él.
State : Permite que un objeto modifique su comportamiento cada vez que
cambie su estado interno.
Strategy : Permite disponer de varios métodos para resolver un
problema y elegir cuál utilizar en tiempo de ejecución.
Template Method : Define en una operación el esqueleto de un
algoritmo, delegando en las subclases algunos de sus pasos, esto
permite que las subclases redefinan ciertos pasos de un algoritmo sin
cambiar su estructura.
Visitor : Permite definir nuevas operaciones sobre una jerarquía de
clases sin modificar las clases sobre las que opera.
CUANDO NO UTILIZAR PATRONES DE DISEÑO?
La primera regla de los patrones de diseño coincide con la primera
regla de la optimización: retrasar. Del mismo modo que no es
aconsejable optimizar prematuramente, no se deben utilizar patrones de
diseño antes de tiempo. Seguramente sea mejor implementar algo primero
y asegurarse de que funciona, para luego utilizar el patrón de diseño
para mejorar las flaquezas; esto es cierto, sobre todo, cuando aún no
ha identificado todos los detalles del proyecto (si se comprende
totalmente el dominio y el problema, tal vez sea razonable utilizar
patrones desde el principio, de igual modo que tiene sentido utilizar
los algoritmos más eficientes desde el comienzo en algunas
aplicaciones).
Nico Megevand
que se comunican para resolver un problema general de diseño en un
contexto particular. Nomina, abstrae e identifica los aspectos clave
de una estructura de diseño común, lo que los hace útiles para crear
un diseño orientado a objetos reutilizable. Identifica las clases e
instancias participantes, sus roles y colaboraciones y la distribución
de responsabilidades. Tiene, en general, 4 elementos esenciales:
NOMBRE: Permite describir, en una o dos palabras, un problema de
diseño junto con sus soluciones y consecuencias. Al dar nombres a los
patrones estamos incrementando nuestro vocabulario de diseño, lo cual
nos permite diseñar y comunicarnos con un mayor nivel de abstracción
(en lugar de hablar de clases individuales nos referimos a
colaboraciones entre clases).
PROBLEMA: Describe cuándo aplicar el patrón. Explica el problema y su
contexto. A veces incluye condiciones que deben darse para que tenga
sentido la aplicación del patrón.
SOLUCIÓN: Describe los elementos que constituyen el diseño, sus
relaciones, responsabilidades y colaboraciones. La solución no
describe un diseño o implementación en concreto, sino que es más bien
una plantilla que puede aplicarse en muchas situaciones diferentes.
CONSECUENCIAS: son los resultados, así como ventajas e inconvenientes
de aplicar el patrón.
Los patrones de diseño no son dogmas que deben ser aceptados. Qué es y
qué no es un patrón de diseño, es una cuestión que depende del punto
de vista de cada uno y del nivel de abstracción en que se trabaje.
Clasificación de patrones de diseño
De Creación: Abstraen el proceso de creación de instancias de objetos.
Ayudan a hacer a un sistema independiente de cómo se crean, se
componen y se representan sus objetos.
Estructurales: Tratan con la composición de clases u objetos. Se
ocupan de cómo las clases y objetos son utilizados para componer
estructuras de mayor tamaño.
De Comportamiento: Caracterizan el modo en que las clases y objetos
interactúan y se reparten la responsabilidad. Atañen a los algoritmos
y a la asignación de responsabilidades entre objetos.