Definición: Encapsular una solicitud en un objeto, lo que le permite parametrizar al cliente utilizando diferentes solicitudes, solicitudes de cola o registros de solicitudes de registro, y proporcionar funciones de revocación y recuperación de comandos.
Tipo: Patrón de comportamiento
Diagrama de clases:
La estructura del modo de comando
Como su nombre indica, el modo de comando es la encapsulación de comandos. Primero, echemos un vistazo a la estructura básica en el diagrama de clase de modo de comando:
Clase de comando: es una clase abstracta que declara los comandos que deben ejecutarse. En términos generales, se debe publicar un método de ejecución al público para ejecutar el comando.
Clase Concretecommand: la clase de implementación de la clase de comando, implementa los métodos declarados en la clase abstracta.
Clase de cliente: la clase final de llamadas al cliente.
Las funciones de las tres clases anteriores deberían ser más fáciles de entender. Centrémonos en la clase de Invoker y la clase Receptier.
Clase de Invoker: la persona que llama es responsable de invocar comandos.
Clase del receptor: el receptor es responsable de recibir y ejecutar comandos.
Para decirlo sin rodeos, la llamada encapsulación de comandos no es más que escribir una serie de operaciones en un método y luego llamar el cliente. Se refleja en el diagrama de clases. Solo se necesita una clase Concretecommand y una clase de cliente para completar la encapsulación de comandos. Incluso si va más allá, para aumentar la flexibilidad, se puede agregar una clase de comando para una abstracción adecuada. ¿Cuál es la función de esta persona que llama y receptor?
De hecho, puede pensar desde otra perspectiva: si simplemente encapsula algunas operaciones como un comando para que otros llamen, ¿cómo se puede llamar un patrón? Como modelo de comportamiento, el modo de comando primero debe lograr un bajo acoplamiento. Solo cuando el grado de acoplamiento es bajo puede mejorar la flexibilidad. El propósito de agregar los roles de la persona que llama y receptor es precisamente para esto.
ejemplo:
La simulación de la operación del TV incluye comandos de encendido, apagado y cambio. El código es el siguiente
// Interfaz para ejecutar el comando de interfaz pública comando {void ejecute (); } // Receptor de comando receptor de clase pública TV {public int currentChannel = 0; public void Turnon () {System.out.println ("El televisino está activado"); } public void gurnoff () {System.out.println ("El televisor está apagado"); } public void ChangeChannel (int Channel) {this.CurrentChannel = canal; System.out.println ("Now TV Channel Is" + Channel); }} // Comando de apagado ConcreteCommand public class CommandOn implementa el comando {private tv mytv; Public Commando (TV TV) {mytv = tv; } public void ejecutute () {mytv.turnon (); }} // Comando de cierre ConcreteCommand public class Commandoff Implements Command {private tv mytv; Public CommandOff (TV TV) {mytv = tv; } public void ejecute () {mytv.TurnOff (); }} // Comando de conmutación de canal ConcreteCommand public class CommandChange Command {private tv mytv; canal privado int; Public CommandChange (TV TV, Int Channel) {mytv = tv; this.channel = canal; } public void ejecute () {mytv.changeChannel (canal); }} // Se puede considerar como un control remoto Invoker Control de clase pública {Comando privado OnCommand, Offcommand, ChangeChannel; Public Control (comando ON, Command Off, Command Channel) {OnCommand = ON; offcommand = off; ChangeChannel = canal; } public void Turnon () {OnCommand.execute (); } public void gurnoff () {OffCommand.Execute (); } public void ChangeChannel () {ChangeChannel.ExeCute (); }} // prueba Cliente de clase Cliente de clase pública Cliente {public static void main (string [] args) {// comando receptor receptor tv mytv = new tv (); // Comando de encendido ConcreteCommond Commando ON = new Commandon (mytv); // Comando de cierre ConcreteCommond comandoff Off = new CommandOff (mytv); // Comando de conmutación de canal ConcreteCommond Commandchange Channel = new Commandchange (mytv, 2); // Control de comando Objeto Invoker Control Control = nuevo control (encendido, apagado, canal); // Power-on Control.Turnon (); // Switch Channel Control.ChangeChannel (); // apagar el control.Turnoff (); }}Resultados de la ejecución
El televisino está encendido. Ahora el canal de televisión es 2 El televisor está apagado.
Ventajas y desventajas del modo de comando
En primer lugar, el modo de comando es muy encapsulación: cada comando está encapsulado, y para el cliente, el comando correspondiente se llama tanto como se necesita la función sin saber cómo se ejecuta el comando. Por ejemplo, hay un conjunto de comandos de operación de archivo: crear un archivo nuevo, copiar un archivo y eliminar un archivo. Si estas tres operaciones están encapsuladas en una clase de comando, el cliente solo necesita saber que hay estas tres clases de comando. En cuanto a la lógica encapsulada en la clase de comando, el cliente no necesita saberlo.
En segundo lugar, el modo de comando tiene una buena escalabilidad. En el modo de comando, la encapsulación más básica de las operaciones en la clase de receptor y la encapsulación secundaria de la clase de comando de estas operaciones básicas. Al agregar nuevos comandos, la escritura de la clase de comando generalmente no es desde cero. Hay una gran cantidad de clases de receptores para llamadas, y también hay una gran cantidad de clases de comando para llamar, y el código es muy reutilizable. Por ejemplo, en la operación de un archivo, necesitamos agregar un comando para cortar un archivo, y solo necesitamos combinar los dos comandos de copiar un archivo y eliminar un archivo, que es muy conveniente.
Finalmente, hablemos de las desventajas del modo de comando, es decir, si hay muchos comandos, será un dolor de cabeza para desarrollarse. Especialmente muchos comandos simples son solo unas pocas líneas de código para implementar. Si usa el modo de comando, no tiene que preocuparse por cuán simple es el comando, debe escribir una clase de comando para encapsularlo.
Escenarios aplicables para el modo de comando
Para la mayoría de las funciones del modo de respuesta de solicitud, es más adecuado usar el modo de comando. Como dice la definición del modo de comando, el modo de comando es más conveniente para implementar funciones, como las operaciones de registro y deshacer.
Resumir
Si usar el modo en una ocasión es una pregunta muy enredada para todos los desarrolladores. A veces, debido a la prevista de algunos cambios en los requisitos, un determinado patrón de diseño se usa para la flexibilidad y la escalabilidad del sistema, pero este requisito previsible no lo hace. Por el contrario, han llegado muchos requisitos imprevisibles, lo que resulta en el patrón de diseño utilizado como el papel opuesto al modificar el código, de modo que todo el equipo del proyecto se quejó. Creo que cada programador ha encontrado tal ejemplo. Por lo tanto, según el principio del desarrollo ágil, cuando diseñamos programas, si podemos resolverlos bien sin usar un determinado patrón de acuerdo con las necesidades actuales, entonces no debemos introducirlo, porque no es difícil introducir un patrón de diseño. Podemos hacerlo en el sistema cuando realmente lo necesitamos para usarlo e introducir este patrón de diseño.
Tome el modo de comando como ejemplo. En nuestro desarrollo, la función de modo de respuesta de solicitud es muy común. En términos generales, encapsularemos la operación de respuesta a la solicitud en un método. Este método encapsulado se puede llamar comando, pero no un modo de comando. Si este diseño debe elevarse a la altura del patrón debe considerarse por separado, porque si se usa el modo de comando, se deben introducir los dos roles de la persona que llama y receptor. La lógica ubicada originalmente en un lugar se dispersa en tres categorías. Al diseñar, es necesario considerar si este costo vale la pena.