码农小汪-设计模式之-命令模式

大话设计模式的例子讲的非常的好，理解起来也方便！有时候忘了。想到这些特殊的例子感觉就是特别爽。

烤羊肉串带来的思考！
路边摊羊肉串：
老板，我这里排的比较先啊，我最先给钱。老板这个没有熟啊。我的是 辣的啊！老板没有放盐啊！场面混乱，已经分不清谁是谁的啊，人太多了。烤肉的质量也受到了影响，心情不好也就不好啊。烤肉的人心情受到了顾客的影响。
店面的烤肉
服务员，给我来两串羊肉串，2鸡翅，啤酒两瓶。
鸡翅没得啦，点别的吧，肉精吧。辣一点。

两者的比较啊：
路边的生意不稳定，往往就是那几个时间，客源不固定的，人多混乱，所以生意也是不稳定的。烤肉的时候谁都想最先吃到啊，烤肉老板一个人，所以忙的混乱啊。所有的人都没有事情，都盯着这里看，烤肉多那一串，考的好，大家都是比较的清楚的。
这里出现了什么关系了呢？
紧耦合
客户和肉串老板的紧耦合，所以容易出错和乱起来，也容易挑剔。这里就是行为的请求者和行为的实现者的紧耦合。我们需要记录哪几个人的羊肉串，有没有特殊的要求（辣不辣），付钱了没有，谁先谁后啊。这个都是请求做什么哦。对于请求的做出记录哦，也就是日志。
如果有人要求撤出请求不要了，或者有人要求重新烤过，这其实就是什么呢？
撤销和重做吧
所以啊，所有的请求排队或者记录日志，一节支持可以撤销的操作等行为时。行为的请求者和实现者之间的紧耦合是不是太合适的。

我们再说说烤肉店吧！
我们不认识烤肉的师傅，见都没有见到。我们只需要给接待的服务员说就好了。她给我们记录，然后将订单交给师傅去做。都有订单，必有先后顺序。不会乱，不会遗忘。
服务员，肉串太多了，给我少一串好？服务员在订单上画了一笔。搞定，然后通知师傅。让服务员解耦我们的客户与烤肉者之间的耦合这的不错哦
编程融入生活！

我们的抽象命令

//抽象命令
    public abstract class Command
    {
        protected Barbecuer receiver;//烤肉串的执行者

        public Command(Barbecuer receiver)
        {
            this.receiver = receiver;
        }

        //执行命令
        abstract public void ExcuteCommand();
    }

这个命令的实现类，考啥子东西呢？考火腿，肌肉，还是其他的一些东西呢？

//烤羊肉串命令
    class BakeMuttonCommand : Command
    {
        public BakeMuttonCommand(Barbecuer receiver)
            : base(receiver)
        { }

        public override void ExcuteCommand()
        {
            receiver.BakeMutton();
        }
    }

    //烤鸡翅命令
    class BakeChickenWingCommand : Command
    {
        public BakeChickenWingCommand(Barbecuer receiver)
            : base(receiver)
        { }

        public override void ExcuteCommand()
        {
            receiver.BakeChickenWing();
        }
    }

我们烤肉的人在干啥呢？

 //烤肉串者
    public class Barbecuer
    {
        public void BakeMutton()
        {
            Console.WriteLine("烤羊肉串!");
        }

        public void BakeChickenWing()
        {
            Console.WriteLine("烤鸡翅!");
        }
    }

还有个重要的人物就是我们的服务员啊，这个解耦的重要的工具。服务员下订单就是让我们的烤肉啊，还是其他的一些东西执行起来，最后的时候才可以去执行的。

    //服务员
    public class Waiter
    {
        private Command command;

        //设置订单
        public void SetOrder(Command command)
        {
            this.command = command;
        }
        //通知执行
        public void Notify()
        {
            command.ExcuteCommand();
        }
    }

最后看我们怎么去执行呢？

              //开店前的准备
            Barbecuer boy = new Barbecuer();  烤肉的人
            Command bakeMuttonCommand1 = new BakeMuttonCommand(boy); 创建一个烤那个啥的，谁去烤呢？就是烤肉的
            Command bakeMuttonCommand2 = new BakeMuttonCommand(boy);
            Command bakeChickenWingCommand1 = new BakeChickenWingCommand(boy);
            Waiter girl = new Waiter();

            //开门营业
            girl.SetOrder(bakeMuttonCommand1);//下个订单，让我们的师傅去执行
            girl.Notify();
            girl.SetOrder(bakeMuttonCommand2);
            girl.Notify();
            girl.SetOrder(bakeChickenWingCommand1);
            girl.Notify();

这个程序肯定是还有问题的吧，真实的情况怎么可以这样的呢？每次只能点一个菜呢，通知一次。
第二嘛，我们不知道厨房的东西是否还有没得？我们应该检查一下涩，让我们的服务员
第三，我们的客户点了哪些菜我们是应该做记录的，以后好收费，还有可能客服中途取消之内的东西。

服务员，有个list的订单

    public class Waiter
    {
        private IList<Command> orders = new List<Command>();

        //设置订单
        public void SetOrder(Command command)
        {
            if (command.ToString() == "命令模式.BakeChickenWingCommand")
            {
                Console.WriteLine("服务员：鸡翅没有了，请点别的烧烤。");
            }
            else
            {
                orders.Add(command);
                Console.WriteLine("增加订单：" + command.ToString() + "  时间：" + DateTime.Now.ToString());
            }
        }

        //取消订单
        public void CancelOrder(Command command)
        {
            orders.Remove(command);
            Console.WriteLine("取消订单：" + command.ToString() + "  时间：" + DateTime.Now.ToString());
        }

        //通知全部执行
        public void Notify()
        {
            foreach (Command cmd in orders)
            {
                cmd.ExcuteCommand();
            }
        }
    }

执行的过程和我们的刚才是一样的哦，所以不要担心的。

命令模式：Command 将我们的一个请求封装成为一个对象，从而使你可用不同的请求对客服进行参数化，对请求排队或记录日志，以及支持可以撤销的操作。
我们看看我们的图片

Command命令设计模式中5个角色：
(1).客户角色：创建了一个具体命令对象并确定其接收者。
Barbecuer boy = new Barbecuer(); 烤肉的人
Command bakeMuttonCommand1 = new BakeMuttonCommand(boy); 命令，烤肉的人是接收者

(2).命令角色：声明了一个给所有具体命令类的抽象接口。这是一个抽象角色，通常由一个java接口或java抽象类实现。
这个就是我们上面的Command,我们的服务员依赖于他。必须有命令服务员才去通知我们的厨房哦

(3).具体命令角色：定义一个接受者和行为之间的弱耦合；实现execute方法，负责调用接收者的相应操作。execute方法通常叫做 执行方法。
这里好理解吧，我们这个方法依赖于我们的具体的执行者，烤肉的人。烤肉的人里面的哪种方法呢？我们烤的是啥子？

(4).请求者（Invoke）角色：负责调用命令对象执行请求，相关的方法叫做行动方法。
这个就是相当于我们的服务员哦，对吧！

(5).接收者（Receiver）角色：负责具体实施和执行一个请求。任何一个类都可以成为接收者，实施和执行请求的方法叫做行动方法。

我们每一个命令的具体的执行者就是他，他就是烤肉的老板

命令模式把发出命令的责任和执行命令的责任分割开，委派给不同的对象。每一个命令都是一个操作，命令请求发出请求要求执行一个操作；命令接受方收到请求，并执行操作。命令模式允许命令请求方和命令接收方独立开来，使得命令请求方不必 知道命令接收方的接口，更不必知道请求是怎么被接收，以及操作是否被执行，何时被执行，以及是怎么被执行的。

服务员

//请求者角色  
class Invoker{  
        private Command command;  
        public Invoker(Command command){  
                this.command = command;  
        }  
        public void action(){  
                command.execute();  
        }  
} 

烤肉的

//接收者  
class Receiver{  
//行动方法  
        public void action(){  
                System.out.println("Action has been taken.");  
        }  
}  

服务员依赖于Command ,Command 依赖于我们的接受者，烤肉的那个人。这样就间接的传达话语！

//抽象命令角色  
interface Command{  
    void execute();  
}  
//具体命令类  
class ConcreteCommand implements Command{  
        private Receiver receiver;  
        public ConcreteCommand(Receiver receiver){  
                this.receiver = receiver;  
        }  
        public void execute(){  
                receiver.action();  
      }  
}  

客服端怎么样呢？

//客户端  
public class Client{  
         public static void main(String[] args){  
        //客户端创建命令接受者
            Receiver receiver = new Receiver();  
        //客户端创建具体命令，并指定命令接受者
             Command command = new ConcreteCommand(receiver);  
        //客户端创建请求者，并给请求者指定具体命令
             Invoker invoker = new Invoker(command);  
        //命令请求者发出命令请求
             invoker.action();         
     }   
}   

Command命令设计模式的优缺点：
优点: 解耦了命令请求者和接受者之间联系。请求者调用一个命令，接受者接受请求并执行相应的动作，因为使用Command模式解耦，请求者无需知道接受者任何接口。
缺点: 造成出现过多的具体命令类。