网页制作注意事项,seo兼职58,随州建设网站,无锡百度信息流23种计模式之 前言 #xff08;5#xff09;单例模式、工厂模式、简单工厂模式、抽象工厂模式、建造者模式、原型模式、(7)代理模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式、桥梁模式、#xff08;11#xff09;策略模式、责任链模式、命令模式、中介者模…23种计模式之 前言 5单例模式、工厂模式、简单工厂模式、抽象工厂模式、建造者模式、原型模式、(7)代理模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式、桥梁模式、11策略模式、责任链模式、命令模式、中介者模式、模板模式、迭代器模式、访问者模式、观察者模式、解释器模式、备忘录模式、状态模式 设计原则
14-Python与设计模式–命令模式
一、饭店点餐系统
又是一个点餐系统原谅作者的吃货属性。不过这次的点餐系统是个饭店的点餐系统。
饭店的点餐系统有什么不同嘛大伙想想看在大多数饭店中当服务员已经接到顾客的点单
录入到系统中后根据不同的菜品会有不同的后台反应。比如饭店有凉菜间、热菜间、主食间
那当服务员将菜品录入到系统中后凉菜间会打印出顾客所点的凉菜条目热菜间会打印出顾客
所点的热菜条目主食间会打印出主食条目。那这个系统的后台模式该如何设计当然
直接在场景代码中加if…else…语句判断是个方法可这样做又一次加重了系统耦合违反了单一职责原则
遇到系统需求变动时又会轻易违反开闭原则。所以我们需要重新组织一下结构。
可以将该系统设计成前台服务员系统和后台系统后台系统进一步细分成主食子系统凉菜子系统热菜子系统。后台三个子系统设计如下
class backSys():def cook(self,dish):pass
class mainFoodSys(backSys):def cook(self,dish):print MAINFOOD:Cook %s%dish
class coolDishSys(backSys):def cook(self,dish):print COOLDISH:Cook %s%dish
class hotDishSys(backSys):def cook(self,dish):print HOTDISH:Cook %s%dish前台服务员系统与后台系统的交互我们可以通过命令的模式来实现服务员将顾客的点单内容封装成命令直接对后台下达命令后台完成命令要求的事即可。 前台系统构建如下
class waiterSys():menu_mapdict()commandList[]def setOrder(self,command):print WAITER:Add dishself.commandList.append(command)def cancelOrder(self,command):print WAITER:Cancel order...self.commandList.remove(command)def notify(self):print WAITER:Nofify...for command in self.commandList:command.execute()前台系统中的notify接口直接调用命令中的execute接口执行命令。 命令类构建如下
class Command():receiver Nonedef __init__(self, receiver):self.receiver receiverdef execute(self):pass
class foodCommand(Command):dishdef __init__(self,receiver,dish):self.receiverreceiverself.dishdishdef execute(self):self.receiver.cook(self.dish)class mainFoodCommand(foodCommand):pass
class coolDishCommand(foodCommand):pass
class hotDishCommand(foodCommand):passCommand类是个比较通过的类foodCommand类是本例中涉及的类相比于Command类进行了一定的改造。
由于后台系统中的执行函数都是cook因而在foodCommand类中直接将execute接口实现如果后台系统执行
函数不同需要在三个子命令系统中实现execute接口。这样后台三个命令类就可以直接继承
不用进行修改了。这里子系统没有变动可以将三个子系统的命令废弃不用直接用foodCommand吗
当然可以各有利蔽。请读者结合自身开发经验进行思考相对于自己业务场景的使用哪种方式更好。
为使场景业务精简一些我们再加一个菜单类来辅助业务菜单类在本例中直接写死。class menuAll:menu_mapdict()def loadMenu(self):#加载菜单这里直接写死self.menu_map[hot] [Yu-Shiang Shredded Pork, Sauteed Tofu, Home Style, Sauteed Snow Peas]self.menu_map[cool] [Cucumber, Preserved egg]self.menu_map[main] [Rice, Pie]def isHot(self,dish):if dish in self.menu_map[hot]:return Truereturn Falsedef isCool(self,dish):if dish in self.menu_map[cool]:return Truereturn Falsedef isMain(self,dish):if dish in self.menu_map[main]:return Truereturn False业务场景如下
if __name____main__:dish_list[Yu-Shiang Shredded Pork,Sauteed Tofu, Home Style,Cucumber,Rice]#顾客点的菜waiter_syswaiterSys()main_food_sysmainFoodSys()cool_dish_syscoolDishSys()hot_dish_syshotDishSys()menumenuAll()menu.loadMenu()for dish in dish_list:if menu.isCool(dish):cmdcoolDishCommand(cool_dish_sys,dish)elif menu.isHot(dish):cmdhotDishCommand(hot_dish_sys,dish)elif menu.isMain(dish):cmdmainFoodCommand(main_food_sys,dish)else:continuewaiter_sys.setOrder(cmd)waiter_sys.notify()打印如下 WAITER:Add dish WAITER:Add dish WAITER:Add dish WAITER:Add dish WAITER:Nofify… HOTDISH:Cook Yu-Shiang Shredded Pork HOTDISH:Cook Sauteed Tofu, Home Style COOLDISH:Cook Cucumber MAINFOOD:Cook Rice 二、命令模式
命令模式的定义为将一个请求封装成一个对象从而可以使用不同的请求将客户端参数化对请求排队或者
记录请求日志可以提供命令的撤销和恢复功能。命令模式中通常涉及三类对象的抽象ReceiverCommand
Invoker本例中的waiterSys。只有一个Invoker的命令模式也可以抽象成一个类似的“星形网络”但与之前介绍的中介者模式不同
单纯的命令模式更像是一个辐射状的结构由Invoker直接对Receiver传递命令而一般不反向传递
中介者模式“星形网络”的中心是个协调者抽象结节间的信息流全部或者部分是双向的。
另外命令模式的定义中提到了“撤销和恢复功能”也给了各位开发人员一个命令模式使用过程中的建议
各个Receiver中可以设计一个回滚接口支持命令的“撤销”。三、命令模式的优点和应用场景
优点
1、低耦合调用者和接收者之间没有什么直接关系二者通过命令中的execute接口联系
2、扩展性好新命令很容易加入也很容易拼出“组合命令”。应用场景
1、触发-反馈机制的系统都可以使用命令模式思想。如基于管道结构的命令系统如SHELL可以直接套用命令模式此外GUI系统中的操作反馈如点击、键入等也可以使用命令模式思想。四、命令模式的缺点
1、如果业务场景中命令比较多那么对应命令类和命令对象的数量也会增加这样系统会膨胀得很大。
