23 Modos de diseño, Capítulo 17: Modo de comando Java
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. El código general para el modo de comando es el siguiente:
clase Invoker {Comando de comando privado; public void setCommand (comando comando) {this.command = command; } public void Action () {this.command.execute (); }} comando de clase abstracta {public abstract void ejecute (); } clase ConcreteCommand extiende el comando {receptor privado receptor; public ConcreteCommand (receptor receptor) {this.Receiver = receptor; } public void ejecutute () {this.Receiver.DoSomething (); }} receptor de clase {public void dosomething () {System.out.println ("Procesamiento lógico de receptor-negocio"); }} Cliente de clase pública {public static void main (string [] args) {receptor receptor = new receptor (); Comando comando = new ConcreteCommand (receptor); // El cliente ejecuta directamente el método de comando específico (este método es consistente con el diagrama de clases) command.execute (); // El cliente ejecuta el comando a través de la persona que llama Invoker Invoker = new Invoker (); invover.setCommand (comando); Invoker.action (); }}A través del código podemos ver que cuando llamamos, el tiempo de ejecución es primero la clase de llamadas, luego la clase de comando y finalmente la clase de receptor. En otras palabras, la ejecución de un comando se divide en tres pasos, y su grado de acoplamiento es mucho más bajo que encapsular todas las operaciones en una clase. Esta es la esencia del patrón de comando: separe la persona que llama del comando y el ejecutor para que ambas partes no tengan que preocuparse por cómo opera la otra parte.
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.
Lo anterior es todo el contenido de este artículo. Espero que sea útil para el aprendizaje de todos y espero que todos apoyen más a Wulin.com.