oop - servicios - ¿Por qué alguna vez usaría una Cadena de Responsabilidad sobre un Decorador?

que trabajo hace un diseñador de interiores

Question

Estoy leyendo sobre el patrón de Cadena de responsabilidad y tengo problemas para imaginar un escenario en el que preferiría su uso sobre el de decorator .

¿Qué piensas? ¿Tiene el CDR un uso de nicho?

Answer 1

1. palabra clave ''extends'' - extensión estática.
2. Patrón decorador - extensión dinámica.
3. Patrón de cadena de responsabilidad: solo el procesamiento de un objeto de comando con un conjunto de objetos de procesamiento y esos objetos no se conocen entre sí.

Answer 2

Bueno, puedo pensar en 2 situaciones:

• No tiene un objeto principal, es decir, no sabe qué hacer con la solicitud después de pasar todas las capas / filtros. (algo así como un aspecto como cadenas de interceptor que realmente no les importa dónde termina la solicitud).
• Debe aplicar selectivamente algún procesamiento previo o posterior a la solicitud. No en una forma de mejora general como lo hace el decorador. es decir, los filtros pueden o no manejar una solicitud específica, pero agregar un decorador siempre mejora el objeto con alguna funcionalidad.

No puedo pensar más en este momento, me encantaría saber más sobre este tema.

Answer 3

Creo que las situaciones para aplicar estos dos patrones son diferentes. Y, por cierto, para el patrón de decorador, el decorador debe conocer el componente que envolvió. Y para el CDR, los diferentes interceptores no podían saber nada el uno del otro.

Answer 4

Decorator se usa cuando desea agregar funcionalidad a un objeto.

COR se utiliza cuando uno de los muchos actores puede tomar medidas en un objeto.

Se llama a un Decorador particular para que realice una acción, según el tipo; mientras que COR pasa el objeto a lo largo de una cadena definida hasta que uno de los actores decide que la acción está completa.

El COR se puede usar cuando existen niveles múltiples de escalación para diferentes manejadores, por ejemplo, un centro de llamadas donde el valor del cliente para la compañía determina si la llamada va a un nivel particular de soporte.

Answer 5

Después de leer las definiciones de la Banda de los Cuatro, no estoy seguro de que haya una diferencia real. (incluido por conveniencia)

• Decorador: permite la envoltura dinámica de objetos para modificar sus responsabilidades y comportamientos existentes
• Cadena de responsabilidad: le da a más de un objeto la oportunidad de manejar una solicitud vinculando los objetos receptores

Wikipedia los desarrolla un poco, pero algunos son un poco arbitrarios.

• Decorator normalmente se implementa como una lista vinculada. Pero creo que es de muy bajo nivel para ser considerado "parte" del patrón.
• Los enlaces de Cadena de responsabilidad solo manejan datos si es su responsabilidad; pero la determinación de la responsabilidad y el manejo de los datos son parte del comportamiento. Los decoradores pueden hacer esto con la misma facilidad.
• Decorator requiere que llames al delegado.
• Un enlace CoR "puro" solo debería llamar al delegado si no maneja los datos.

Los primeros dos atributos realmente no distinguen los patrones. Los otros dos sí, pero la forma en que Decorator y CoR usualmente se implementan no hacen cumplir esos atributos: el diseñador simplemente espera que nadie escriba un Decorador que rompa la cadena o un CoRLink que continúa la cadena después de manejar los datos.

Para implementar estos atributos, necesitarías algo como lo siguiente.

Decorador forzado:

abstract class Decorated {
public Decorated delegate;
public final Object doIt(Object args) {
Object returnVal = behavior(arg);
if(delegate != null) returnVal = delegate.doit(returnVal);
return returnVal;
}
protected abstract Object behavior(Object args); //base or subclass behavior
}

Cadena de responsabilidad forzada:

abstract class Link {
public Link delegate;
public final Object processIt(Obect args) {
Object returnVal = args;
if(isMyResponsibility) returnVal = processingBehavior(returnVal);
else returnVal = delegate.processIt(returnVal);
return returnVal;
}
protected abstract Boolean isMyResponsibility(Object args);
protected abstract Object processingBehavior(Object args);
}

(Alternativamente, podría simplemente agregar una línea al javadoc, si lo único que desea es eximirse de la responsabilidad en caso de que alguien más estropee su diseño, pero ¿por qué dejarlo al azar?)

Answer 6

Estoy de acuerdo en que desde el punto de vista estructural, estos dos patrones son muy similares. Mi pensamiento es sobre el comportamiento final:

En la interpretación clásica del elemento CoR que maneja la solicitud se rompe la cadena.

Si algún elemento en el decorador rompe la cadena, será una implementación incorrecta del decorador, porque la parte base del comportamiento se perderá. Y la idea de decorador es la incorporación transparente de un nuevo comportamiento cuando el comportamiento de la base permanece intacto.

Answer 7

La diferencia entre estos patrones no está relacionada con cuándo o cómo se puede romper la cadena (lo que supone una cadena) o cuándo se ejecuta el comportamiento adicional. Están relacionados porque ambos usan la composición a favor de la herencia para proporcionar una solución más flexible.

La diferencia clave es que un decorador agrega un nuevo comportamiento que, de hecho, amplía la interfaz original. Es similar a cómo la extensión normal puede agregar métodos, excepto que la "subclase" solo está acoplada por una referencia, lo que significa que se puede usar cualquier "superclase".

El patrón COR puede modificar un comportamiento existente que es similar a anular un método existente usando herencia. Puede elegir llamar a super.xxx () para continuar en la "cadena" o manejar el mensaje usted mismo.

Entonces la diferencia es sutil, pero un ejemplo de un decorador debería ayudar:

interface Animal
{
Poo eat(Food food);
}
class WalkingAnimal implements Animal
{
Animal wrapped;
WalkingAnimal(Animal wrapped)
{
this.wrapped = wrapped;
}
Position walk(Human walker)
{
};
Poo eat(Food food)
{
return wrapped.eat(food);
}
}
class BarkingAnimal implements Animal
{
Animal wrapped;
BarkingAnimal(Animal wrapped)
{
this.wrapped = wrapped;
}
Noise bark()
{
};
Poo eat(Food food)
{
bark();
return wrapped.eat();
}
}

Puedes ver que podemos componer un animal ladrando y caminando ... o de hecho agregamos la habilidad de ladrar a cualquier animal. Para utilizar este comportamiento adicional directamente, deberíamos mantener una referencia al decorador BarkingAnimal.

Todos los BarkingAnimal también ladran una vez antes de comer, lo que ha cambiado la funcionalidad existente y, por lo tanto, es similar a un COR. Pero la intención no es la misma que COR, es decir, encontrar un Animal de muchos que comerán la comida. La intención aquí es modificar el comportamiento.

Se podría imaginar que se aplicará un COR para encontrar un humano que lleve al animal a dar un paseo. Esto podría implementarse como una lista enlazada como chained arriba o como una Lista explícita ... o lo que sea.

Espero que esto sea razonablemente claro!

John

Answer 8

Yo diría que una Cadena de Responsabilidad es una forma particular de Decorador .

Answer 9

Decorador

1. Decorator patrón Decorator permite que el comportamiento se agregue dinámicamente a un objeto individual.

2. Proporciona una alternativa flexible a la subclasificación para ampliar la funcionalidad. A pesar de que usa herencia, hereda de la interfaz del Denominador Común Más Bajo (LCD).

Diagrama UML para decorador

Consecuencias:

1. Con la decoración también es posible eliminar las funcionalidades añadidas dinámicamente.
2. La decoración agrega funcionalidad a los objetos en tiempo de ejecución, lo que dificultaría la funcionalidad del sistema de depuración.

Enlaces útiles:

Cuándo usar el patrón decorador?

Decorator de wikipedia

decorator de origen

Cadena de responsabilidad:

El patrón de cadena de responsabilidad es un patrón de diseño que consiste en una fuente de objetos de comando y una serie de objetos de procesamiento. Cada objeto de procesamiento contiene lógica que define los tipos de objetos de comando que puede manejar; el resto se pasan al siguiente objeto de procesamiento en la cadena

Diagrama UML

Este patrón es más efectivo cuando:

1. Más de un objeto puede manejar un comando
2. El manejador no se conoce de antemano
3. El controlador debe determinarse automáticamente
4. Se desea que la solicitud se dirija a un grupo de objetos sin especificar explícitamente su receptor
5. El grupo de objetos que pueden manejar el comando se debe especificar de una manera dinámica

Enlaces útiles:

Chain-of-responsibility_pattern de wikipedia

chain-of-responsibility-pattern de chain-of-responsibility-pattern de oodesign

chain_of_responsibility de sourcemaking

Ejemplo del mundo real: en una empresa, un rol designado tiene límites particulares para procesar la solicitud de compra. Si la persona con un rol designado no tiene suficiente poder para aprobar la factura de compra, enviará el comando / solicitud a su sucesor, que tiene más poder. Esta cadena continuará hasta que se procese el comando.

Answer 10

Cadena

Evite acoplar el remitente de una solicitud a su receptor dando a más de un objeto la oportunidad de manejar la solicitud. Encadena los objetos receptores y pasa la solicitud a lo largo de la cadena hasta que un objeto la maneje.

vs

Decorador

Adjunte responsabilidades adicionales a un objeto dinámicamente. Los decoradores proporcionan una alternativa flexible a las subclases para ampliar la funcionalidad.

Yo diría que es sobre el orden en que las cosas sucederán. Si los encadena, se llamará a lo largo de la cadena. Con un decorador no se garantiza este orden, solo se pueden adjuntar responsabilidades adicionales.

Answer 11

El hecho de que pueda romper la cadena en cualquier punto diferencia el patrón de Cadena de responsabilidad del patrón Decorador . Se puede pensar que los decoradores se ejecutan todos a la vez sin ninguna interacción con los otros decoradores. Se puede pensar que los enlaces en una cadena se ejecutan uno a la vez, porque cada uno depende del enlace anterior.

Utilice el patrón Cadena de responsabilidad cuando pueda conceptualizar su programa como una cadena compuesta por enlaces, donde cada enlace puede manejar una solicitud o pasarla por la cadena.

Cuando solía trabajar con la API Win32, a veces necesitaba usar la funcionalidad de enlace que proporciona. Enganchar un mensaje de Windows sigue aproximadamente el patrón de Cadena de responsabilidad. Cuando enganchó un mensaje como WM_MOUSEMOVE, se invocará su función de devolución de llamada. Piense en la función de devolución de llamada como el último enlace de la cadena. Cada enlace de la cadena puede decidir si descarta el mensaje WM_MOUSEMOVE o lo pasa por la cadena al siguiente enlace.

Si se usó el patrón Decorator en ese ejemplo, se le habría notificado el mensaje WM_MOUSEMOVE, pero no podrá evitar que otros ganchos lo manipulen también.

Otro lugar donde se usa el patrón de Cadena de mando es en motores de juegos. De nuevo, puede conectar funciones del motor, eventos y otras cosas. En el caso de un motor de juego, no desea simplemente agregar funcionalidad. Desea agregar funcionalidad e impedir que el motor del juego realice su acción predeterminada.