Este documento explica el patrón de diseño Chain of Responsibility. Se describe cómo evita el acoplamiento entre una solicitud y su receptor, permitiendo que más de un objeto pueda manejar la solicitud de forma serial. Explica cómo la capa de presentación genera una "burbuja de notificaciones" al solicitar ayuda a la capa intermedia o de aplicación dependiendo del caso. Finalmente, concluye que este patrón reduce acoplamiento y añade flexibilidad para asignar responsabilidades entre objetos.

1. PROGRAMACIÓN DE APLICACIONES
Prof.Milton Joel Batres Márquez
Patrón de Diseño: Chain of Responsibility
Adam Jairo Márquez Rojas
Diana Argones Galaviz
Erick Leonardo Ruiz Sànchez
09/12/2013

2. Objetivo del Patrón: Evitar el Acoplamiento de una solicitud desde el remitente hasta
su receptor, dandoa más de un objeto la oportunidad de manejar la petición.
Notificación de Forma serial:
El sujeto le envía una notificación a un Objeto A que puede enviársela a un objeto B y
el objeto B a un receptor final o incluso si el Objeto A es el receptor final detienen el
proceso de la notificación.
Sujeto
Objeto A
Objeto B
Receptor
Veamos un ejemplo donde simularemos un programa en el cual pediremos ayuda del
programa dependiendo del tipo de ayuda que se solicita vamos a ver cómo se
comporta la cadena de responsabilidad y la ayuda sale por pantalla dependiendo
quién o de cuál de los objetos es el que debe responder a la notificación a la solicitud
de ayuda.
Comportamiento de la Cadena de Responsabilidad.
Aplicación
Capa Intermedia
Capa de Presentación
Get Ayuda()
La funcionalidad del Programa:
Tenemos una capa de aplicación, una capa intermedia la cual se va a comunicar entre
la aplicación y la capa de presentación y una capa de presentación la cual va a utilizar
el usuario para obtener la ayuda.
Desde la capa de presentación el usuario va a solicitar ayuda a la capa de
presentación a la capa intermedia o a la capa de aplicación, eso va depender del
parámetro que le enviemos al método get ayuda.
Como vemos la cadena de responsabilidad hace que la capa de presentación genere
una burbuja de notificaciones es decir la capa de presentación le notifica a la capa
intermedia que se está solicitando ayuda y si la capa intermedia aún no puede
responder esa ayuda o no es solicitada la ayuda a esta capa le solicitara la capa de
aplicación generar la ayuda.
Aquí vemos la cadena de responsabilidad como genera la notificación en forma serial
entre cada una de las capas y si una de las capas es la encargada de generar la
ayuda detiene el proceso de notificación hacia las capas.

3. Material para la realización de la práctica:
Comenzamos con la Interface InterfaceAyuda la cual va a tener un método get ayuda y
este método recibe un parámetro de tipo entero para identificar cuál de las capas es la
que debe responder a la solicitud de ayuda todas las capas deben implementar esta
interface para poder realizar el comportamiento de Responsabilidad.
Comenzamos con la capa de presentación en este caso la llamamos FrontEnd
La cual implementa la clase InterfaceAyuda comienza con un atributo privado llamado
TIPO_AYUDA el cual es un valor final el cual no se puede cambiar será siempre uno
también tiene un parámetro de tipo InterfaceAyuda el cual va a ser el sucesor de la
cadena de responsabilidad.
En su constructor recibimos como parámetro un objeto que implementa la interface
ayuda y al atributo sucesor le asignamos esa interface que se ha recibido.
Sobrescribimos el método getAyuda el cual recibe un parámetro de tipo entero para
identificar si la ayuda que estamos solicitando es el mismo valor de TIPO_AYUDA de
la clase FrontEnd en este caso si el valor del método get ayuda que envía el usuario
es uno, lo que se hace es que se imprime es que ¨ La ayuda se está generando desde
el FrontEnd.¨. Si no es uno lo que realiza es llamar el método getAyuda de su sucesor
enviándole el valor que ha solicitado el cliente. Con esto lo que hacemos es que le

4. asignamos la responsabilidad de obtener la ayuda al objeto sucesor de este objeto
Front End.
Esta clase la hemos llamado Middle la cual implementa también la interface ayuda.
Tiene un atributo final que se llama TIPO_AYUDA al cual le asignamos el valor de
dos también tiene un atributo Interface_Ayuda el cual va a ser el sucesor de esta capa
en su constructor enviamos un objeto que implementa la interface ayuda y a su
atributo sucesor le asignamos el valor enviado en este constructor, al igual que en la
clase anterior sobre escribimos el método getAyuda y validamos si la ayuda es de tipo
dos significa que la ayuda debe responderla la capa intermedia y se informara que se
está generando desde la clase intermedia de lo contrario le asigna la responsabilidad a
su sucesor de generar la ayuda y le envía el parámetro solicitado por el cliente.
Esta es otra gran ventaja de la cadena de responsabilidad observemos que esta clase
la cual llamamos aplicación va a simular la capa de aplicación implementa la interface
ayuda pero el constructor no es igual a los otros objetos es decir que los objetos a los
cuales está notificando no deben ser iguales no necesariamente pueden ser iguales,
pueden serlo como pueden no serlo. En este caso el constructor de la capa aplicación
es masivo no va a recibir ningún sucesor sobre escribimos el método getAyuda y en

5. este caso no preguntamos nada porque la capa aplicación es el último objeto en la
cadena de responsabilidad así que es el último tiene que arrojar que la ayuda se ha
generado desde la base.
Aquí tenemos la clase que va a testar el patrón de diseño instanciamos un objeto del
método scanner, creamos la opción para capturar lo que digita el usuario final.
Creamos tres objetos de las diferentes clases que componen la cadena de
responsabilidad un objeto de aplicación, un objeto intermediario o que va a ser de la
clase intermedia la cual en su constructor recibe como parámetro la Aplicación que ya
hemos creado previamente y la creamos la capa de presentación la cual va a recibir
como sucesor el objeto intermediario.
Creamos un ciclo para que el usuario pueda escoger cualquiera de las opciones hasta
que seleccione terminar la aplicación mostramos por pantalla un menú sencillo donde
se le dan las opciones al usuario para que pueda digitar, capturamos la opción que ha
digitado el usuario. Si la opción es uno la capa de presentación devolverá de inmediato
la ayuda, si la opción es dos la capa de presentación le asignara la responsabilidad a
su sucesor de devolver la ayuda requerida y si la opción es tres en vista que la capa
intermediaria no pude responder esta ayuda esta capa intermediario le asignara la
responsabilidad a la capa de aplicación de devolver la ayuda, se termina el ciclo y
probamos lo aplicativo.

6. Ejecutamos el programa:
Nos aparece el menú de selección. Digitamos la opción 1 Cuando digitamos la opción
uno el objeto que tiene la responsabilidad de devolver la ayuda es la capa de
presentación
Nos aparecerá que la ayuda fue generada desde Frame es decir desde la capa de
presentación.
Como tenemos un ciclo que hasta digitamos cero no nos salimos entonces
seleccionamos la opción 2 La capa de presentación le ha enviado la responsabilidad a
la capa intermedia de generar la ayuda solicitada. Seleccionamos la opción 3 y aquí se
puede ver como la capa de presentación no puede responder a la solicitud le envía la
responsabilidad a la capa intermedia, la capa intermedia tampoco puede responder a
la solicitud le envía la responsabilidad a la capa de aplicación y esta responde ayuda
desde la base de aplicación.
Diagrama de Flujo del Programa:
Clase Aplicación.
ClaseFrontEnd.

7. Interface Ayuda.
Clase Middle implementa la interface ayuda.

8. Conclusiones:
Tenemos como conclusión de este patrón:
Reduce el acoplamiento.
Añade flexibilidad para asignar responsabilidades a objetos.
No se garantiza la recepción.
Permite establecer una cadena de objetos receptores a través de los cuales se pasa
una petición formulada por un objeto emisor. La idea es que cualquiera de los
receptores puede responder a la petición en función de un criterio establecido.
Encadena los objetos receptores y pasa la petición a través de la cadena hasta que es
procesada por algún objeto.
Busca evitar un montón de if – else largos y complejos en nuestro código, pero sobre
todas las cosas busca evitar que el cliente necesite conocer toda nuestra estructura
jerárquica y que rol cumple cada integrante de nuestra estructura.
En múltiples ocasiones, un cliente necesita que se realice una función, pero o no
conoce al servidor concreto de esa función o es conveniente que no lo conozca para
evitar un gran acoplamiento entre ambos.
Se utiliza cuando:
Las peticiones emitidas por un objeto deben ser atendidas por distintos objetos
receptores.
No se sabe a priori cual es el objeto que me puede resolver el problema.
Cuando un pedido debe ser manejado por varios objetos.
El conjunto de objetos que pueden tratar una petición debería ser especificado
dinámicamente.
La motivación detrás de este patrón es crear un sistema que pueda servir a diversas
solicitudes de manera jerárquica. En otras palabras, si un objeto que es parte de un
sistema no sabe cómo responder a una solicitud, la pasa a lo largo del árbol de
objetos. Como el nombre lo implica, cada objeto de dicho árbol puede tomar la
responsabilidad y atender la solicitud.
Un ejemplo típico podría ser el lanzar un trabajo de impresión. El cliente no sabe
siquiera qué impresoras están instaladas en el sistema, simplemente lanza el trabajo a
la cadena de objetos que representan a las impresoras. Cada uno de ellos lo deja
pasar, hasta que alguno, finalmente lo ejecuta.
Hay un desacoplamiento evidente entre el objeto que lanza el trabajo (el cliente) y el
que lo realiza (impresora).

9. Cuestionario:
1-Patron Builder
Porque abstrae el proceso de creación de un objeto complejo?
Que patrones están relacionados con el suyo?
Porque no es conveniente utilizar su patrón
Porque los objetos que dependen de un algoritmo tendrán que cambiar
cuando el algoritmo cambia?
2-Patron Prototype
o
Porque no es conveniente utilizar su patrón
o
Diferencias de Clonación profunda vs Clonación superficial
o
Cuando se debe utilizar este patrón
3-Patron Adapter
o
Gracias a que problemáticas surge el patrón Adapter
o
Este patrón se debe de utilizar cuando
o
Si bien el Adaptar tiene una implementación relativamente sencilla,
se puede llevar a cabo con varias técnicas, menciona una de ellas?
4-Patron Decorator
o
Aplicabilidad del patrón decorator
o
Consecuencias del patrón decorator
o
¿si el patrón no es dependiente de la herencia porque hablamos de
SuperClases?
5-Patrón Proxy
o
Aplicabilidad del patrón proxy
o
Dime 3 tipos de proxys y su aplicabilidad
o
Consecuencias

10. 6-Patrón Modelo de vista controlador
Menciona la construcción de dos componentes distintos del MVC
Por qué deben de comunicarse el modelo, la vista y el controlador
A que se refiere con modelo pasivo
Ventajas de utilizar MVC
7-Patrón Observer
Como se conforma el patrón observador
Aplicabilidad del patrón observador
Consecuencias del patrón observador
8-Patron visitor
Consecuencias del patrón Visitor
Aplicabilidad del patrón Visitor
Cuando se debe de utilizar este patrón
9-Memento
¿Cuál es la intención del patrón memento dentro de una aplicación para una
empresa que desarrolla una base de datos para almacenar libros?
¿Porque el patrón memento no se aplica cuando todo o parte del estado de un
objeto debe ser guardado para ser restaurado más tarde?
¿Porque Memento es una mala alternativa de diseño, para guardar el estado
interno de un objeto
Preservando la encapsulación?
¿Dónde o en que te basas para argumentar que el patrón memento es una
buena alternativa de diseño?

11. 10-Fecade
¿Cuál es el motivo de del fecade?
¿Para qué utilizarías el fecade dentro de un sistema?
¿El abstract factory y el mediator que son?
11-Composite
¿Cuándo usas el patrón compositor?
¿Cuáles pueden ser los participantes de composite?
¿Menciona una consecuencia de usar composite?
12-Abstract factory
¿En qué consiste el método de fábrica abstracta?
¿Dame un ejemplo de donde usar el método?
¿Un problema de la fábrica abstracta?
13-Estado
¿Cuál es su objetivo?
¿Cuál es la utilización?
¿Cuál es tu conclusión de este estado?

12. Bibliografía:
http://dukechile.blogspot.mx/2008/08/el-patrn-cadena-de-responsabilidad.html
http://www.youtube.com/watch?v=Y3zwnT_5P5k
http://www.youtube.com/watch?v=Y3zwnT_5P5k
http://migranitodejava.blogspot.mx/2011/06/visitor.html
http://unpocodejava.wordpress.com/category/patrones/
http://es.cyclopaedia.net/wiki/Flyweight-(patron-de-diseno)-1
http://ocw.usal.es/ensenanzas-tecnicas/ingenieria-del-software/contenidos/Tema6-DOO1pp.pdf
http://www.rms.nsw.gov.au/heavyvehicles/cor/enforcement_statistics/
https://www.nhvr.gov.au/safety-accreditation-compliance/chain-of-responsibility/about-thechain-of-responsibility
http://patronesdediseno.blogspot.mx/2009/05/patron-chain-of-responsability.html
http://unpocodesensatez.com.ar/?p=362.
http://books.google.com.mx/books/about/Patrones_de_Dise%C3%B1o.html?id=t_WWZwEAC
AAJ&redir_esc=y.