Patrón de comando parece innecesariamente complejo (¿qué no estoy entendiendo?)

Question

He leído sobre el patrón de comando, y creo que me falta algo. El objeto Command existe para abstraer los detalles del objeto Receiver. Me parece que simplemente podríamos detenernos aquí y mantener referencias a los objetos Command para ejecutar el método apropiado en el momento apropiado.

¿Por qué, entonces, es necesario el Invoker? ¿Qué ventaja proporciona esta indirección adicional? Ya hemos ocultado los detalles del receptor detrás del comando, ¿cuál es la motivación para que el comando se oculte también al cliente?

Answer 1

Bueno, si lo pones de esa manera, parece bastante complejo, pero a menudo un Receptor no necesita ser un objeto en absoluto. Puede ser poco más que una función que se ejecuta (como un evento). Además, el invocador no necesita ser una clase. Es solo lo que desencadena el comando. Esto también puede ser un controlador de eventos en un botón.

Incluso Wikipedia resume un par de ejemplos donde se usa este patrón sin tener que implementar clases separadas para invocador y receptor. Un ejemplo es un diálogo de asistente, donde la GUI rellena el objeto de comando y un botón de Finalización lo desencadena. Entonces, esa clase de GUI (que tiene de todos modos) es tanto el cliente como el invocador.

Answer 2

Según lo que puedo decir, el objetivo del patrón es tener algún tipo de productor de comandos y algún tipo de consumidor de comandos, pero permitir al productor crear o modificar comandos sin que el consumidor cambie.

El patrón llama al productor "Cliente" y al consumidor "Invitante".

Es una devolución de llamada OO.

Por qué, entonces, es el invocador necesario

Por lo que yo puedo decir por all the examples on Wikipedia, el invocador no tiene una forma definida. Es simplemente un código que acepta un comando abstracto.

Me parece que simplemente podíamos parar aquí, y mantener las referencias a objetos de comando

Si tiene sentido en su código para lo que invoca comandos para aceptar o mantener las referencias a los comandos abstractos , entonces ya has implementado el invocador.

Si un bit de código es tanto el productor como el consumidor, el patrón de comando no tiene valor. Solo vale la pena cuando pases comandos abstractos a algo que quiera invocarlos.

Answer 3

Si está pasando diferentes tipos de comandos, Invoker es útil. Puede usar el mismo Invoker para la ejecución de diferentes comandos concretos. En un nodo diferente, etiquetar Receiver con ConcreteCommand en lugar de Invoker permite un acoplamiento flojo. El Receiver puede cambiar el nombre del método (por ejemplo SwitchON a swithcOnTV) como en este ejemplo:

Post relacionados: Using Command Design pattern

Para entender el propósito de Invoker, me gustaría hacer referencia este article el restaurante & Casos de uso del centro de servicio del automóvil.

El camarero (Invoker) toma la orden del Customer en su libreta. El Order se pone en cola para la orden de cocción y se dirige al cocinero (Receiver) donde se procesa.

El cliente es el Customer. Él envía su solicitud al Receiver a través del camarero, que es el Invoker. El camarero encapsula el comando (el orden en este caso) escribiéndolo en el cheque y luego lo coloca, creando el objeto ConcreteCommand que es el comando mismo.

El Receiver será el cocinero que, después de completar el trabajo en todos los pedidos que se le enviaron antes del comando en cuestión, comienza a trabajar en él.

Otro aspecto notable del ejemplo es el hecho de que el panel para los pedidos no admite únicamente los pedidos del menú, por lo que puede admitir comandos para cocinar muchos elementos diferentes.