每个模式都在传递着一种与众不同的编程理念。每次都仿佛是站在巨人的上,一步步的学习,积土成山。
最近学习了命令模式,喜欢它很简单:开篇从小菜大鸟吃肉串谈起,慢慢的吸引着我的注意力,因为感兴趣,所以有了进一步的研究。
【命令模式】
1.定义:将一个请求封装为一个对象,从而使你可用不同的请求对客户进行参数化;对请求排队或记录请求日志,以及支持可撤销的操作。
2.如图所示:
很简单,抽象出来命令类,然后定义一个实现命令类的接口。与此有直接联系的是命令执行者和命令发出者,但是根据弱耦合原则,具体的命令执行者和命令的发出者之间没有直接的关联,Invoker类实现了命令的上传下达,是命令得以实现的关键因素。
3.个人理解
代码总是在需求的变化中不断优化的。
At first:大鸟和小菜去街边小摊上吃烧烤,大家也都亲历过在大街上买烤串:消费者提出消费请求-烧烤老板根据需求执行烧烤动作-一手交钱一手交货。这对于小批量的消费人群来说,没有什么不合理的地方,但是随着消费人群的扩大,消费量的增加,就会给烧烤老板带来一定的压力,如果老板足够精明还好,要是记性不好的话,就会造成不必要的损失。拽个设计模式术语:这叫做耦合性太强。
//烤肉串者 public class Barbecure { //烤羊肉 public void BackMutton() { Console.WriteLine("烤羊肉串!"); } //烤鸡翅 public void BakeChickenWing() { Console.WriteLine("烤鸡翅"); } }
then:【烧烤店VS烧烤摊】因为不太满意烧烤摊老板的服务,小菜建议去烧烤店吃,在这里就不一样了,烧烤店里有专门的服务人员来记录顾客需求并且发出消费通知,形成日志记录各种需求,达到有迹可循的目的,不会因为记不清楚而算错帐了。于是形成了如下需求模式——松耦合设计
//抽象命令类 public abstract class Command { protected Barbecuer receiver; public Command(Barbecuer receiver) { this.receiver = receiver; } abstract public void ExcuteCommand(); } //服务员类 public class Waiter { private Command command; public void SetOrder(Command command) { this.command = command; } public void Notify() { command.ExcuteCommand(); } }
抽象出来了服务员类(用于记录顾客需求信息,形成日志资料),服务员要做的是:当顾客点完餐后通知厨房去做。这样就避免了顾客直接与烧烤老板的联系,也就减少了不必要的纠纷。但是,这样问题就又来了,如果供应不充足,在这里需要有一个很长时间的信息确认时间,也就是说物料不充足时,不应该是顾客来判断是否还有,应该是服务员提供物料供应信息,这样才算是“全心全意为人民服务”——优化的松耦合设计
Today:人性化的服务满足了消费者的需求。继续对代码进行优化设计:将物料供应信息全部提供给服务员,这样在顾客点餐的时候不会出现不必要的麻烦。使用命令模式可以很好地解决这个问题。
//服务员类 public class Waiter { private IList<Command> orders = new List<Command>(); //设置订单 public void SetOrder(Command command) { if (command.ToString() == "命令模式.BakeChikenWingCommand") { 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(); } } }这样,就万事俱备啦。
总结一下命令模式的优点: