Diferencia entre revisiones de «Chain of Responsibility»
(Página creada con ''''Patrón Chain of Responsibility''' thumb|right|398x254px|Estructura Patrón Chain of Responsibility ''Categoría de Patrón'': Diseño<br...') |
m (Texto reemplazado: «<div align="justify">» por «») |
||
| (No se muestran 9 ediciones intermedias de 4 usuarios) | |||
| Línea 1: | Línea 1: | ||
| − | + | {{Definición | |
| − | + | |nombre=Chain of Responsibility | |
| − | '' | + | |imagen=Chain_of_responsability.jpg |
| − | '' | + | |tamaño= |
| − | ==Propósito== | + | |concepto=Permite establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la petición en función de un criterio establecido. |
| − | Evita | + | }} |
| − | ==Motivación== | + | |
| − | La idea de este patrón es | + | |
| − | 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 | + | '''Chain of Responsibility'''. Permite establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la petición en función de un criterio establecido. |
| − | ==Aplicabilidad== | + | |
| + | == 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: | 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. | |
| − | ==Estructura== | + | *El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente. |
| − | [[Archivo:ChainofResponsibility.jpg]] | + | |
| + | == Estructura == | ||
| + | |||
| + | [[Archivo:ChainofResponsibility.jpg]] | ||
| + | |||
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. | |
| − | ==Colaboraciones== | + | *Manejador Concreto: 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. |
| − | Cuando un | + | *Cliente: Inicializa la petición a un objeto ''ManejadorConcreto'' de la cadena. |
| − | objeto '' | + | |
| − | ==Consecuencias== | + | == Colaboraciones == |
| − | + | ||
| − | + | Cuando un cliente envía una petición, ésta se propaga a través de la cadena hasta que un | |
| − | + | ||
| − | ==Patrones relacionados== | + | objeto ''Manejador Concreto'' se hace responsable de procesarla. |
| − | Este patrón se suele aplicar conjuntamente con el [[Patrón Composite]], en el que los | + | |
| − | padres de los componentes pueden actuar como sucesores. | + | == Consecuencias == |
| − | ==Fuentes== | + | |
| − | + | *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). | ||
| + | *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. | ||
| + | |||
| + | |||
[[Category:Ciencias_informáticas]] | [[Category:Ciencias_informáticas]] | ||
última versión al 14:41 20 jun 2019
| ||||||
Chain of Responsibility. Permite establecer una cadena de objetos receptores a través de los cuales se pasa una petición formulada por un objeto emisor. Cualquiera de los objetos receptores puede responder a la petición en función de un criterio establecido.
Sumario
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:
- 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.
- El conjunto de objetos que pueden tratar una petición debería ser especificado dinámicamente.
Estructura
Una estructura de objetos típica podría parecerse a ésta:
Participantes
- Manejador*: Define una interfaz para tratar las peticiones. Opcionalmente, implementa el enlace al sucesor.
- Manejador Concreto: 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
Cuando un cliente envía una petición, ésta se propaga a través de la cadena hasta que un
objeto Manejador Concreto se hace responsable de procesarla.
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).
- 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.
