UML关系简单介绍
UML简单使用的介绍
创建型设计模式
Android设计模式-单例模式
Android设计模式-工厂模式
Android设计模式-抽象工厂模式
Android设计模式-建造者模式
Android设计模式-原型模式
结构型设计模式
Android设计模式-代理模式
Android设计模式-装饰模式
Android设计模式-适配器模式
Android设计模式-组合模式
Android设计模式-门面模式
Android设计模式-桥接模式
Android设计模式-享元模式
行为型设计模式
Android设计模式-策略模式
Android设计模式-命令模式
Android设计模式-责任链模式
Android设计模式-模版方法模式
Android设计模式-迭代器模式
Android设计模式-观察者模式
Android设计模式-备忘录模式
Android设计模式-中介者模式
Android设计模式-访问者模式
Android设计模式-状态模式
Android设计模式-解释器模式
1.定义
命令模式是一种高内聚的模式。讲一个请求封装成一个对象，从而让你使用不同的请求把客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。
2.命令模式UML图
图中，Client与Invoker的关系为关联关系，没有连上。。
角色介绍
- Invoker 调用者角色，接受命令，执行命令
- Command 抽象命令，定义一些基本方法
- ConcreteCommand 具体命令，继承抽象命令，并持有接收者的引用，通过接受者调用相应方法
- Receiver 接收者角色，命令传到这里就是要被执行了，就相当于具体的干活的
- Client 客户端。。没啥说的
3.简单实现
3.1抽象命令角色
public abstract class Command {
public abstract void execute();
}
3.2具体命令角色
public class ConcreteCommand extends Command {
private Receiver receiver;
public ConcreteCommand(Receiver receiver) {
this.receiver = receiver;
}
@Override
public void execute() {
this.receiver.doSomething();
}
}
具体命令持有一个接受者的引用。当命令明确下来后，也就是通知接收者进行相应当操作。
3.3接收者角色
public class Receiver {
public void doSomething(){
System.out.println("收到消息开始干活");
}
}
接收者当方法内，做你想要做当操作，另外，接收者有可能也不是一个，如果要有多个不同当接收者，那么就抽象出来一个抽象接收者，然后写出多个具体接收者就可以了，参考抽象命令与具体命令。
3.4 调用者角色
public class Invoker {
private Command command;
public Invoker(Command command) {
this.command = command;
}
public void action(){
this.command.execute();
}
}
调用者持有具体当命令，明确调用哪条命令。
3.5客户端
public class MyClass {
public static void main(String args[]) {
Receiver receiver=new Receiver();
Command command=new ConcreteCommand(receiver);
Invoker invoker=new Invoker(command);
invoker.action();
}
}
打印结果为
收到消息开始干活
从例子和结果中看，貌似将过程复杂化了，但是这么做必然是有其优点的。在下面的优点中说。
另外，在一般情况下，接收者最好也封装到具体到命令中，这样也可以避免接收者暴露在高层模块中。
4.总结
4.1优点
- 类间解耦 调用者和接收者之间没有任何依赖或者引用关系。调用者只需要通过相应的具体命令就可以得出最后的结果，而不必了解具体是哪个接收者做的操作。
- 可扩展性 Command的子类可以很容易扩展，调用者与高层模块也没有很强的耦合。
4.2缺点
- 命令多的时候会非常多。。
4.3使用场景
- 在你所有认为是命令的地方都可以使用命令模式，具体使用与否看具体的设计了。。。
