definición:
Encapsule una solicitud como un objeto, de modo que pueda parametrizar clientes con diferentes solicitudes; poner solicitudes en cola o registrar registros de solicitudes, y admitir operaciones reversibles.
Estructura: (imagen en el libro, intrusión y eliminación)
Una clase de comando abstracta
Varias clases de comando específicas
Clases de destinatarios para determinadas órdenes de ejecución específicas
Un invocador
No hay una clase de cliente, todas las solicitudes se realizan directamente a través de la clase de mensaje
Ejemplos:
Cuando se trata de pedidos, pienso en el emperador, y luego pienso en más de un cliente, pero el emperador solo tiene uno, pero no es importante, el punto no está aquí.
Las órdenes del emperador generalmente se les dicen directamente a los jefes eunucos que lo rodean que no encontrará a nadie para dar órdenes en persona, y es posible que realmente no conozca a las doncellas eunucas que están debajo.
entonces ... El modo de comando también es adecuado aquí.
Hice algunos cambios, primero pegué el código y luego lo elaboré.
Chicas de palacio (destinataria):
package designpattern.command;
/*
* 宫女
*/
public class Maid {
String name;
public Maid(String name) {
this.name = name;
}
public void clean() {
System.out.println(this.name + ":打扫卫生");
}
}Eunuco (destinatario):
package designpattern.command;
/*
* 太监
*/
public class Eunuch {
String name;
public Eunuch(String name) {
this.name = name;
}
public void carrySedanChair() {
System.out.println(this.name + ":抬轿子");
}
}Interfaz de comando abstracto:
package designpattern.command;
public interface Command {
public void execute();
}Clase de comando de limpieza (clase de comando específica):
package designpattern.command;
public class CleanCommand implements Command {
private Maid maid;
public CleanCommand(Maid maid) {
this.maid = maid;
}
@Override
public void execute() {
maid.clean();
}
}Clase de comando de elevación del sedán (clase de comando específica):
package designpattern.command;
public class CarrySedanChairCommand implements Command {
private Eunuch eunuch;
public CarrySedanChairCommand(Eunuch eunuch) {
this.eunuch = eunuch;
}
@Override
public void execute() {
eunuch.carrySedanChair();
}
}Jefe eunuco (invocador):
package designpattern.command;
import java.util.ArrayList;
import java.util.List;
public class ManagerEunuch {
private List<Command> commands = new ArrayList<Command>();
public void setCommand(Command command) {
this.commands.add(command);
}
public void notifyIt() {
for (Command command : commands) {
command.execute();
}
}
}Cliente:
package designpattern.command;
public class Client {
public static void main(String[] args) {
Maid xiaocui = new Maid("小翠");
Maid xiaohua = new Maid("小花");
Eunuch xiaozhuozi = new Eunuch("小卓子");
Eunuch xiaoguizi = new Eunuch("小贵子");
Command cleanCommand1 = new CleanCommand(xiaocui);
Command cleanCommand2 = new CleanCommand(xiaohua);
Command carrySedanChairCommand1 = new CarrySedanChairCommand(xiaozhuozi);
Command carrySedanChairCommand2 = new CarrySedanChairCommand(xiaoguizi);
ManagerEunuch ligongong = new ManagerEunuch();
ligongong.setCommand(cleanCommand1);
ligongong.setCommand(cleanCommand2);
ligongong.setCommand(carrySedanChairCommand1);
ligongong.setCommand(carrySedanChairCommand2);
ligongong.notifyIt();
}
}Salida de resultado:
Komidori: limpieza de flores: limpieza pequeña zhuozi: silla de manos pequeña Takako: silla de manos
Originalmente pensé que debería haber muchos tipos de receptores de órdenes. Por ejemplo, en mi ejemplo, hay damas de la corte y eunucos. Pero mi sensación real es que esto es más adecuado para un solo artista.
Aunque he implementado varios ejecutores, los ejecutores y los comandos específicos están profundamente acoplados. Por ejemplo, el comando de limpieza (CleanCommand) tiene una instancia de la dama de la corte (ejecutor).
Si el eunuco quiere limpiar, debe crear otra clase de comando de limpieza con una instancia del eunuco. Aunque puede abstraer una clase principal ejecutora y dejar que todas contengan instancias de esta clase principal, no puede llamar a father.clean (), A menos que defina este método en la clase principal, pero siempre que la clase secundaria agregue un método, la clase principal debe aumentar en consecuencia, lo que obviamente no es un buen diseño. No he pensado en una buena forma de resolver este problema por el momento, así que creo que puede ser más adecuado para un solo tipo de artista.
emmm, acabo de pensarlo de nuevo. Puede ser que haya un problema con la clasificación de albaceas en mi ejemplo. Puede ser que el alcance del trabajo de cada albacea sea bastante diferente. Por ejemplo, en mi ejemplo, puede haber 50% de damas de palacio y eunucos. Los trabajos se superponen, si los clasificamos por tipos específicos de trabajos, como los de la cocina imperial y la lavandería, no habrá problema. Puede considerarse como un malentendido del pensamiento. aprende una leccion.
para resumir:
Creo que los puntos escritos en el libro son bastante buenos, así que citémoslos aquí.
Primero, puede diseñar fácilmente una cola de comandos;
En segundo lugar, es más fácil registrar comandos cuando sea necesario;
En tercer lugar, permita que la parte que recibe la solicitud decida si la rechaza.
En cuarto lugar, puede cancelar y rehacer fácilmente la solicitud;
En quinto lugar, debido a que agregar una nueva clase de comando específica no afecta a otras clases, es fácil agregar una nueva clase de comando específica.
La ventaja clave es que el modo de comando separa el objeto que solicita una operación del objeto que sabe cómo realizar una operación.