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

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.

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.

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.

Sujeto Objeto A Objeto B Receptor

Get Ayuda()

Aplicación

Capa Intermedia

Capa de Presentación

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

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

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.

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.

Interface Ayuda.

Clase Middle implementa la interface ayuda.

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).

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

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?

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?

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-DOO-

1pp.pdf

http://www.rms.nsw.gov.au/heavyvehicles/cor/enforcement_statistics/

https://www.nhvr.gov.au/safety-accreditation-compliance/chain-of-responsibility/about-the-

chain-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.