《head first 设计思想》day six 命令模式

命令模式的定义：将请求封装成对象，这可以让你使用不同的对象（请求、队列、或者日志）来参数化其他对象，命令模式可以支持撤销操作。主要目的是把命令的发出者和执行者，以及命令解耦。

书中的例子讲的是智能家居遥控器例子：一个遥控器插板，有多个插槽，可以供我们扩展。每一个插槽可以插入一个芯片，每个芯片意味着可以控制一款智能家居，比如电视，电灯，洗衣机，空调，音响等。插槽旁边就是打开与关闭开关（一个芯片对应一组on/off开关）。如果我们设计的话，应该怎么设计.

我们可以联想到我们生活中的例子，比如去西餐厅（因为老外的设计模式是从老外的日常生活中总结的，我们也模拟老外的环境），我们都是找服务员下单，然后单子流转到后厨，不同的厨师根据不同的菜品烹制，有的烤面包，有的烤牛排，有的做甜点，有的做炸鱼。。我们不可能亲自下厨做菜，否则整个餐厅就乱套了。

这一篇日志我写了两天，但是我没能写完，因为我发现其实我没太明白作者讲的这个--遥控器插板--例子，我觉得这不是一个好的例子，因为外国人的脑回路毕竟跟我们还是有差别的，我也不希望自己生搬硬套的给大家写出来某个例子误导大家，而且我今天看了jack床长的blog，发现读起来真有意思，知识性和趣味性兼顾，由浅入深，鞭辟入里。回头看我自己的blog发现易读性很差，也没有讲到重点，出现这样的情况真是很尴尬，说明我自己理解也不透彻。之前看许令波大神的blog他也讲到一点：我们自己学习了，认为了解了，那就讲给别人听，看看别人能不能理解，如果别人理解说明自己真的会了，如果别人不理解，说明我们自己的逻辑有问题，需要自己再整理一次，再讲给别人听。而写blog这件事情，也要这样，自己整理了，写出来，如果自己看不懂，那自己的逻辑更有问题，从自我认为理解，到让别人理解的过程，才是掌握知识的过程。那我觉得自己写的不好有那么几点，类图没画出来，逻辑不完整，设计思路也不完整。所以我决定这篇博客仔细画类图；

基本代码入下

class Order extends Command{
     private Client client;
     private Receiver receiver;
     private String menu;
     void excute(){
          receiver.action();
     }
}

class Resturant{
    private Client client;
    private Invoker waitress;
    void open(){
        Command command = new Order();
        order.setClient(clinet);
        order.setMenu("甜点");
        waitress.addCommand(command);
        waitress.notify();
    }
}

class Waitress  extends Invoker{
  private List<Command> commands;
  private Receiver receiver;
  void addCommand(Command command){
      if(command.getMenu()=="甜品"){
        command.setRecevier(pastryChef);
      }
      commands.add(command);
  }
 void notify(){
    for(Command command:commands){
       command.excute();
    }
 }
 void cancel(Command command){
    commands.delete(command);
 }
}

class PastryChef extends Receiver{
    void action(){
       syso("正在做甜品");  
    }
}

上面是很简单的代码实现，现实中的命令模式其实复杂一点，比如Netty中就用到了命令模式，成为reaction模型，不过之前我看netty的时候，没有看明白，而且rpc框架有时候可以依赖netty做链接，上个项目我用netty做了一个消息推送，但是团队觉得太不成熟，选择了极光，要是当时能一直研究下去，没准就做了自己的rpc框架了，哈哈哈，真是意淫