Diferencia entre revisiones de «Chain of Responsibility»

Línea 1: Línea 1:
 
{{Normalizar}}
 
{{Normalizar}}
 +
   
 
'''Patrón Chain of Responsibility'''
 
'''Patrón Chain of Responsibility'''
[[Image: ChainofResponsibility.jpg|thumb|right|398x254px|Estructura Patrón Chain of Responsibility]]
+
   
 +
[[Image:       ChainofResponsibility.jpg|thumb|right|398x254px|Patrón Chain of Responsibility]]
 +
   
 
''Categoría de Patrón'': Diseño<br>
 
''Categoría de Patrón'': Diseño<br>
 +
   
 
''Categoría de Problema'': Organización del trabajo
 
''Categoría de Problema'': Organización del trabajo
 +
   
 
==Propósito==
 
==Propósito==
Evita [[acoplar]] el [[emisor]] de una petición a su [[receptor]], dando a más de un objeto la posibilidad de responder a la petición. Encadena los objetos receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto.
+
   
 +
Evita acoplar el emisor de una petición a su receptor, dando a       más de un objeto la posibilidad de responder a la petición.       Encadena los objetos receptores y pasa la petición a través de la       cadena hasta que es procesada por algún objeto.
 +
   
 
==Motivación==
 
==Motivación==
La idea de este patrón es [[desacoplar]] a los emisores y a los receptores dándole a varios objetos la posibilidad de tratar una petición, que se pasa a través de una cadena de objetos hasta que es procesada por alguno de ellos.<br>
+
   
Para reenviar la petición a lo largo de la cadena, garantizando que los receptores permanezcan implícitos, cada objeto de la cadena comparte una [[interfaz]] común para procesar peticiones y para acceder a su sucesor en la cadena.
+
La idea de este patrón es desacoplar a los emisores y a los       receptores dándole a varios objetos la posibilidad de tratar una       petición, que se pasa a través de una cadena de objetos hasta que       es procesada por alguno de ellos.<br>
 +
   
 +
Para reenviar la petición a lo largo de la cadena, garantizando       que los receptores permanezcan implícitos, cada objeto de la       cadena comparte una interfaz común para procesar peticiones y para       acceder a su sucesor en la cadena.
 +
   
 
==Aplicabilidad==
 
==Aplicabilidad==
 +
   
 
Usar Chain of Responsability cuando:
 
Usar Chain of Responsability cuando:
#Hay más de un objeto que puede manejar una petición y el manejador no se conoce a priori, sino que debería determinarse automáticamente.
+
   
#Se quiere enviar una petición a un objeto entre varios sin especificar explícitamente el [[receptor]].
+
#Hay más de un objeto que puede manejar una petición y el       manejador no se conoce a priori, sino que debería determinarse       automáticamente.
#El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente.
+
   
 +
#Se quiere enviar una petición a un objeto entre varios sin       especificar explícitamente el receptor.
 +
   
 +
#El conjunto de objetos que pueden tratar una petición debería       ser especificado dinámicamente.
 +
   
 
==Estructura==
 
==Estructura==
 +
   
 
[[Archivo:ChainofResponsibility.jpg]]<br>
 
[[Archivo:ChainofResponsibility.jpg]]<br>
 +
   
 
Una estructura de objetos típica podría parecerse a ésta:
 
Una estructura de objetos típica podría parecerse a ésta:
 +
   
 
[[Archivo:Chain.jpg]]
 
[[Archivo:Chain.jpg]]
 +
   
 
==Participantes==
 
==Participantes==
# ''Manejador'': Define una [[interfaz]] para tratar las peticiones. Opcionalmente, implementa el enlace al sucesor.
+
   
# ''ManejadorConcreto'': Trata las peticiones de las que es responsable. Puede acceder a su sucesor. Si el ''ManejadorConcreto'' puede manejar la petición, lo hace; en caso contrario la reenvía a su sucesor.
+
# ''Manejador'': Define una interfaz para tratar las peticiones.       Opcionalmente, implementa el enlace al sucesor.
# ''Cliente'': Inicializa la petición a un objeto ''ManejadorConcreto'' de la cadena.
+
   
 +
# ''ManejadorConcreto'': Trata las peticiones de las que es       responsable. Puede acceder a su sucesor. Si el       ''ManejadorConcreto'' puede manejar la petición, lo hace; en caso       contrario la reenvía a su sucesor.
 +
   
 +
# ''Cliente'': Inicializa la petición a un objeto       ''ManejadorConcreto'' de la cadena.
 +
   
 
==Colaboraciones==
 
==Colaboraciones==
Cuando un [[cliente]] envía una petición, ésta se propaga a través de la cadena hasta que un
+
   
 +
Cuando un [[cliente]] envía una petición, ésta se propaga a       través de la cadena hasta que un
 +
   
 
objeto ''ManejadorConcreto'' se hace responsable de procesarla.
 
objeto ''ManejadorConcreto'' se hace responsable de procesarla.
 +
   
 
==Consecuencias==
 
==Consecuencias==
# ''Reduce el acoplamiento'': Libera a un objeto de tener que saber que otro objeto maneja una petición. Ni el [[emisor]] ni el [[receptor]] se conocen y tampoco tienen que conocer la estructura de la cadena. Simplifica las interconexiones entre objetos. En vez de que los objetos mantengan referencias a todos los posibles receptores, solo tienen una única referencia a su sucesor (Ventaja).
+
   
# ''Añade flexibilidad para asignar responsabilidades a objetos '': Se pueden añadir o cambiar responsabilidades para tratar una petición modificando la cadena en tiempo de ejecución (Ventaja).
+
# ''Reduce el acoplamiento'': Libera a un objeto de tener que       saber que otro objeto maneja una petición. Ni el emisor ni el       receptor se conocen y tampoco tienen que conocer la estructura de       la cadena. Simplifica las interconexiones entre objetos. En vez de       que los objetos mantengan referencias a todos los posibles       receptores, solo tienen una única referencia a su sucesor       (Ventaja).
# ''No se garantiza la recepción '': Dado que las peticiones no tienen un receptor explícito, no hay garantía de que sean manejadas (la petición puede alcanzar el final de la cadena sin haber sido procesada). Una petición también puede quedar sin tratar cuando la cadena no está configurada correctamente (Desventaja).
+
   
 +
# ''Añade flexibilidad para asignar responsabilidades a objetos       '': Se pueden añadir o cambiar responsabilidades para tratar una       petición modificando la cadena en tiempo de ejecución (Ventaja).
 +
   
 +
# ''No se garantiza la recepción '': Dado que las peticiones no       tienen un receptor explícito, no hay garantía de que sean       manejadas (la petición puede alcanzar el final de la cadena sin       haber sido procesada). Una petición también puede quedar sin       tratar cuando la cadena no está configurada correctamente       (Desventaja).
 +
   
 
==Patrones relacionados==
 
==Patrones relacionados==
Este patrón se suele aplicar conjuntamente con el [[Patrón Composite]], en el que los
+
   
 +
Este patrón se suele aplicar conjuntamente con el [[Patrón       Composite]], en el que los
 +
   
 
padres de los componentes pueden actuar como sucesores.
 
padres de los componentes pueden actuar como sucesores.
 +
   
 
==Fuentes==
 
==Fuentes==
Erich Gamma. Patrones de Diseño.  
+
   
 +
Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides.       Patrones de Diseño.Elementos de software orientado a objetos      reutilizable, 1995.
 +
   
 
[[Category:Ciencias_informáticas]]
 
[[Category:Ciencias_informáticas]]

Revisión del 14:38 8 nov 2011

Patrón Chain of Responsibility

Patrón Chain of Responsibility

Categoría de Patrón: Diseño

Categoría de Problema: Organización del trabajo

Propósito

Evita acoplar el emisor de una petición a su receptor, dando a más de un objeto la posibilidad de responder a la petición. Encadena los objetos receptores y pasa la petición a través de la cadena hasta que es procesada por algún objeto.

Motivación

La idea de este patrón es desacoplar a los emisores y a los receptores dándole a varios objetos la posibilidad de tratar una petición, que se pasa a través de una cadena de objetos hasta que es procesada por alguno de ellos.

Para reenviar la petición a lo largo de la cadena, garantizando que los receptores permanezcan implícitos, cada objeto de la cadena comparte una interfaz común para procesar peticiones y para acceder a su sucesor en la cadena.

Aplicabilidad

Usar Chain of Responsability cuando:

  1. Hay más de un objeto que puede manejar una petición y el manejador no se conoce a priori, sino que debería determinarse automáticamente.
  1. Se quiere enviar una petición a un objeto entre varios sin especificar explícitamente el receptor.
  1. El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente.

Estructura

ChainofResponsibility.jpg

Una estructura de objetos típica podría parecerse a ésta:

Chain.jpg

Participantes

  1. Manejador: Define una interfaz para tratar las peticiones. Opcionalmente, implementa el enlace al sucesor.
  1. ManejadorConcreto: Trata las peticiones de las que es responsable. Puede acceder a su sucesor. Si el ManejadorConcreto puede manejar la petición, lo hace; en caso contrario la reenvía a su sucesor.
  1. Cliente: Inicializa la petición a un objeto ManejadorConcreto de la cadena.

Colaboraciones

Cuando un cliente envía una petición, ésta se propaga a través de la cadena hasta que un

objeto ManejadorConcreto se hace responsable de procesarla.

Consecuencias

  1. Reduce el acoplamiento: Libera a un objeto de tener que saber que otro objeto maneja una petición. Ni el emisor ni el receptor se conocen y tampoco tienen que conocer la estructura de la cadena. Simplifica las interconexiones entre objetos. En vez de que los objetos mantengan referencias a todos los posibles receptores, solo tienen una única referencia a su sucesor (Ventaja).
  1. Añade flexibilidad para asignar responsabilidades a objetos : Se pueden añadir o cambiar responsabilidades para tratar una petición modificando la cadena en tiempo de ejecución (Ventaja).
  1. No se garantiza la recepción : Dado que las peticiones no tienen un receptor explícito, no hay garantía de que sean manejadas (la petición puede alcanzar el final de la cadena sin haber sido procesada). Una petición también puede quedar sin tratar cuando la cadena no está configurada correctamente (Desventaja).

Patrones relacionados

Este patrón se suele aplicar conjuntamente con el Patrón Composite, en el que los

padres de los componentes pueden actuar como sucesores.

Fuentes

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides. Patrones de Diseño.Elementos de software orientado a objetos reutilizable, 1995.