策略模式
一、客户消息通知
假设某司维护着一些客户资料，需要在该司有新产品上市或者举行新活动时通知客户。现通知客户的方式有两种：短信通知、邮件通知。应如何设计该系统的客户通知部分？为解决该问题，我们先构造客户类，包括客户常用的联系方式和基本信息，同时也包括要发送的内容。
class customer:
customer_name=""
snd_way=""
info=""
phone=""
email=""
def setPhone(self,phone):
self.phone=phone
def setEmail(self,mail):
self.email=mail
def getPhone(self):
return self.phone
def getEmail(self):
return self.email
def setInfo(self,info):
self.info=info
def setName(self,name):
self.customer_name=name
def setBrdWay(self,snd_way):
self.snd_way=snd_way
def sndMsg(self):
self.snd_way.send(self.info)
snd_way向客户发送信息的方式，该方式置为可设，即可根据业务来进行策略的选择。
发送方式构建如下：
class msgSender:
dst_code=""
def setCode(self,code):
self.dst_code=code
def send(self,info):
pass
class emailSender(msgSender):
def send(self,info):
print "EMAIL_ADDRESS:%s EMAIL:%s"%(self.dst_code,info)
class textSender(msgSender):
def send(self,info):
print "TEXT_CODE:%s EMAIL:%s"%(self.dst_code,info)
在业务场景中将发送方式作为策略，根据需求进行发送。
if __name__=="__main__":
customer_x=customer()
customer_x.setName("CUSTOMER_X")
customer_x.setPhone("10023456789")
customer_x.setEmail("customer_x@xmail.com")
customer_x.setInfo("Welcome to our new party!")
text_sender=textSender()
text_sender.setCode(customer_x.getPhone())
customer_x.setBrdWay(text_sender)
customer_x.sndMsg()
mail_sender=emailSender()
mail_sender.setCode(customer_x.getEmail())
customer_x.setBrdWay(mail_sender)
customer_x.sndMsg()
结果打印如下：
PHONE_NUMBER:10023456789 TEXT:Welcome to our new party!
EMAIL_ADDRESS:customer_x@xmail.com EMAIL:Welcome to our new party!
二、策略模式
策略模式定义如下：定义一组算法，将每个算法都封装起来，并使他们之间可互换。以上述例子为例，customer类扮演的角色（Context）直接依赖抽象策略的接口，在具体策略实现类中即可定义个性化的策略方式，且可以方便替换。
上一节中我们介绍了桥接模式，仔细比较一下桥接模式和策略模式，如果把策略模式的Context设计成抽象类和实现类的方式，那么策略模式和桥接模式就可以划等号了。从类图看上去，桥接模式比策略模式多了对一种角色（抽象角色）的抽象。二者结构的高度同构，也只能让我们从使用意图上去区分两种模式：桥接模式解决抽象角色和实现角色都可以扩展的问题；而策略模式解决算法切换和扩展的问题。
三、策略模式的优点和应用场景
优点：
1、各个策略可以自由切换：这也是依赖抽象类设计接口的好处之一；
2、减少代码冗余；
3、扩展性优秀，移植方便，使用灵活。
应用场景：
1、算法策略比较经常地需要被替换时，可以使用策略模式。如现在超市前台，会常遇到刷卡、某宝支付、某信支付等方式，就可以参考策略模式。
四、策略模式的缺点
1、项目比较庞大时，策略可能比较多，不便于维护；
2、策略的使用方必须知道有哪些策略，才能决定使用哪一个策略，这与迪米特法则是相违背的。
责任链模式
一、请假系统
假设有这么一个请假系统：员工若想要请3天以内（包括3天的假），只需要直属经理批准就可以了；如果想请3-7天，不仅需要直属经理批准，部门经理需要最终批准；如果请假大于7天，不光要前两个经理批准，也需要总经理最终批准。类似的系统相信大家都遇到过，那么该如何实现呢？首先想到的当然是if…else…，但一旦遇到需求变动，其臃肿的代码和复杂的耦合缺点都显现出来。简单分析下需求，“假条”在三个经理间是单向传递关系，像一条链条一样，因而，我们可以用一条“链”把他们进行有序连接。
构造抽象经理类和各个层级的经理类：
class manager():
successor = None
name = ''
def __init__(self, name):
self.name = name
def setSuccessor(self, successor):
self.successor = successor
def handleRequest(self, request):
pass
class lineManager(manager):
def handleRequest(self, request):
if request.requestType == 'DaysOff' and request.number <= 3:
print '%s:%s Num:%d Accepted OVER' % (self.name, request.requestContent, request.number)
else:
print '%s:%s Num:%d Accepted CONTINUE' % (self.name, request.requestContent, request.number)
if self.successor != None:
self.successor.handleRequest(request)
class departmentManager(manager):
def handleRequest(self, request):
if request.requestType == 'DaysOff' and request.number <= 7:
print '%s:%s Num:%d Accepted OVER' % (self.name, request.requestContent, request.number)
else:
print '%s:%s Num:%d Accepted CONTINUE' % (self.name, request.requestContent, request.number)
if self.successor != None:
self.successor.handleRequest(request)
class generalManager(manager):
def handleRequest(self, request):
if request.requestType == 'DaysOff':
print '%s:%s Num:%d Accepted OVER' % (self.name, request.requestContent, request.number)
class request():
requestType = ''
requestContent = ''
number = 0
request类封装了假期请求。在具体的经理类中，可以通过setSuccessor接口来构建“责任链”，并在handleRequest接口中实现逻辑。场景类中实现如下：
if __name__=="__main__":
line_manager = lineManager('LINE MANAGER')
department_manager = departmentManager('DEPARTMENT MANAGER')
general_manager = generalManager('GENERAL MANAGER')
line_manager.setSuccessor(department_manager)
department_manager.setSuccessor(general_manager)
req = request()
req.requestType = 'DaysOff'
req.requestContent = 'Ask 1 day off'
req.number = 1
line_manager.handleRequest(req)
req.requestType = 'DaysOff'
req.requestContent = 'Ask 5 days off'
req.number = 5
line_manager.handleRequest(req)
req.requestType = 'DaysOff'
req.requestContent = 'Ask 10 days off'
req.number = 10
line_manager.handleRequest(req)
打印如下：
LINE MANAGER:Ask 1 day off Num:1 Accepted OVER
LINE MANAGER:Ask 5 days off Num:5 Accepted CONTINUE
DEPARTMENT MANAGER:Ask 5 days off Num:5 Accepted OVER
LINE MANAGER:Ask 10 days off Num:10 Accepted CONTINUE
DEPARTMENT MANAGER:Ask 10 days off Num:10 Accepted CONTINUE
GENERAL MANAGER:Ask 10 days off Num:10 Accepted OVER
二、责任链模式
责任链模式的定义如下：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。
需要说明的是，责任链模式中的应该只有一个处理者，也就是说，本例中的“最终批准”为该对象所谓的“请求处理”。
三、责任链模式的优点和应用场景
优点：
1、将请求者与处理者分离，请求者并不知道请求是被哪个处理者所处理，易于扩展。
应用场景：
1、若一个请求可能由一个对请求有链式优先级的处理群所处理时，可以考虑责任链模式。除本例外，银行的客户请求处理系统也可以用责任链模式实现（VIP客户和普通用户处理方式当然会有不同）。
四、责任链模式的缺点
1、如果责任链比较长，会有比较大的性能问题；
2、如果责任链比较长，若业务出现问题，比较难定位是哪个处理者的问题。
命令模式
一、饭店点餐系统
又是一个点餐系统（原谅作者的吃货属性）。不过这次的点餐系统是个饭店的点餐系统。饭店的点餐系统有什么不同嘛？大伙想想看，在大多数饭店中，当服务员已经接到顾客的点单，录入到系统中后，根据不同的菜品，会有不同的后台反应。比如，饭店有凉菜间、热菜间、主食间，那当服务员将菜品录入到系统中后，凉菜间会打印出顾客所点的凉菜条目，热菜间会打印出顾客所点的热菜条目，主食间会打印出主食条目。那这个系统的后台模式该如何设计？当然，直接在场景代码中加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_map=dict()
commandList=[]
def setOrder(self,command):
print "WAITER:Add dish"
self.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 = None
def __init__(self, receiver):
self.receiver = receiver
def execute(self):
pass
class foodCommand(Command):
dish=""
def __init__(self,receiver,dish):
self.receiver=receiver
self.dish=dish
def execute(self):
self.receiver.cook(self.dish)
class mainFoodCommand(foodCommand):
pass
class coolDishCommand(foodCommand):
pass
class hotDishCommand(foodCommand):
pass
Command类是个比较通过的类，foodCommand类是本例中涉及的类，相比于Command类进行了一定的改造。由于后台系统中的执行函数都是cook，因而在foodCommand类中直接将execute接口实现，如果后台系统执行函数不同，需要在三个子命令系统中实现execute接口。这样，后台三个命令类就可以直接继承，不用进行修改了。（这里子系统没有变动，可以将三个子系统的命令废弃不用，直接用foodCommand吗？当然可以，各有利蔽。请读者结合自身开发经验，进行思考相对于自己业务场景的使用，哪种方式更好。）
为使场景业务精简一些，我们再加一个菜单类来辅助业务，菜单类在本例中直接写死。
class menuAll:
menu_map=dict()
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 True
return False
def isCool(self,dish):
if dish in self.menu_map["cool"]:
return True
return False
def isMain(self,dish):
if dish in self.menu_map["main"]:
return True
return False
业务场景如下：
if __name__=="__main__":
dish_list=["Yu-Shiang Shredded Pork","Sauteed Tofu, Home Style","Cucumber","Rice"]#顾客点的菜
waiter_sys=waiterSys()
main_food_sys=mainFoodSys()
cool_dish_sys=coolDishSys()
hot_dish_sys=hotDishSys()
menu=menuAll()
menu.loadMenu()
for dish in dish_list:
if menu.isCool(dish):
cmd=coolDishCommand(cool_dish_sys,dish)
elif menu.isHot(dish):
cmd=hotDishCommand(hot_dish_sys,dish)
elif menu.isMain(dish):
cmd=mainFoodCommand(main_food_sys,dish)
else:
continue
waiter_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
二、命令模式
命令模式的定义为：将一个请求封装成一个对象，从而可以使用不同的请求将客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。命令模式中通常涉及三类对象的抽象：Receiver，Command，Invoker（本例中的waiterSys）。
只有一个Invoker的命令模式也可以抽象成一个类似的“星形网络”，但与之前介绍的中介者模式不同，单纯的命令模式更像是一个辐射状的结构，由Invoker直接对Receiver传递命令，而一般不反向传递，中介者模式“星形网络”的中心，是个协调者，抽象结节间的信息流全部或者部分是双向的。
另外，命令模式的定义中提到了“撤销和恢复功能”，也给了各位开发人员一个命令模式使用过程中的建议：各个Receiver中可以设计一个回滚接口，支持命令的“撤销”。
三、命令模式的优点和应用场景
优点：
1、低耦合：调用者和接收者之间没有什么直接关系，二者通过命令中的execute接口联系；
2、扩展性好：新命令很容易加入，也很容易拼出“组合命令”。
应用场景：
1、触发-反馈机制的系统，都可以使用命令模式思想。如基于管道结构的命令系统（如SHELL），可以直接套用命令模式；此外，GUI系统中的操作反馈（如点击、键入等），也可以使用命令模式思想。
四、命令模式的缺点
1、如果业务场景中命令比较多，那么对应命令类和命令对象的数量也会增加，这样系统会膨胀得很大。
中介者模式
一、仓储管理系统
有一个手机仓储管理系统，使用者有三方：销售、仓库管理员、采购。需求是：销售一旦达成订单，销售人员会通过系统的销售子系统部分通知仓储子系统，仓储子系统会将可出仓手机数量减少，同时通知采购管理子系统当前销售订单；仓储子系统的库存到达阈值以下，会通知销售子系统和采购子系统，并督促采购子系统采购；采购完成后，采购人员会把采购信息填入采购子系统，采购子系统会通知销售子系统采购完成，并通知仓库子系统增加库存。
从需求描述来看，每个子系统都和其它子系统有所交流，在设计系统时，如果直接在一个子系统中集成对另两个子系统的操作，一是耦合太大，二是不易扩展。为解决这类问题，我们需要引入一个新的角色-中介者-来将“网状结构”精简为“星形结构”。（为充分说明设计模式，某些系统细节暂时不考虑，例如：仓库满了怎么办该怎么设计。类似业务性的内容暂时不考虑）
首先构造三个子系统，即三个类（在中介者模式中，这些类叫做同事些）：
class colleague():
mediator = None
def __init__(self,mediator):
self.mediator = mediator
class purchaseColleague(colleague):
def buyStuff(self,num):
print "PURCHASE:Bought %s"%num
self.mediator.execute("buy",num)
def getNotice(self,content):
print "PURCHASE:Get Notice--%s"%content
class warehouseColleague(colleague):
total=0
threshold=100
def setThreshold(self,threshold):
self.threshold=threshold
def isEnough(self):
if self.total<self.threshold:
print "WAREHOUSE:Warning...Stock is low... "
self.mediator.execute("warning",self.total)
return False
else:
return True
def inc(self,num):
self.total+=num
print "WAREHOUSE:Increase %s"%num
self.mediator.execute("increase",num)
self.isEnough()
def dec(self,num):
if num>self.total:
print "WAREHOUSE:Error...Stock is not enough"
else:
self.total-=num
print "WAREHOUSE:Decrease %s"%num
self.mediator.execute("decrease",num)
self.isEnough()
class salesColleague(colleague):
def sellStuff(self,num):
print "SALES:Sell %s"%num
self.mediator.execute("sell",num)
def getNotice(self, content):
print "SALES:Get Notice--%s" % content
当各个类在初始时都会指定一个中介者，而各个类在有变动时，也会通知中介者，由中介者协调各个类的操作。
中介者实现如下：
class abstractMediator():
purchase=""
sales=""
warehouse=""
def setPurchase(self,purchase):
self.purchase=purchase
def setWarehouse(self,warehouse):
self.warehouse=warehouse
def setSales(self,sales):
self.sales=sales
def execute(self,content,num):
pass
class stockMediator(abstractMediator):
def execute(self,content,num):
print "MEDIATOR:Get Info--%s"%content
if content=="buy":
self.warehouse.inc(num)
self.sales.getNotice("Bought %s"%num)
elif content=="increase":
self.sales.getNotice("Inc %s"%num)
self.purchase.getNotice("Inc %s"%num)
elif content=="decrease":
self.sales.getNotice("Dec %s"%num)
self.purchase.getNotice("Dec %s"%num)
elif content=="warning":
self.sales.getNotice("Stock is low.%s Left."%num)
self.purchase.getNotice("Stock is low. Please Buy More!!! %s Left"%num)
elif content=="sell":
self.warehouse.dec(num)
self.purchase.getNotice("Sold %s"%num)
else:
pass
中介者模式中的execute是最重要的方法，它根据同事类传递的信息，直接协调各个同事的工作。
在场景类中，设置仓储阈值为200，先采购300，再卖出120，实现如下：
if __name__=="__main__":
mobile_mediator=stockMediator()#先配置
mobile_purchase=purchaseColleague(mobile_mediator)
mobile_warehouse=warehouseColleague(mobile_mediator)
mobile_sales=salesColleague(mobile_mediator)
mobile_mediator.setPurchase(mobile_purchase)
mobile_mediator.setWarehouse(mobile_warehouse)
mobile_mediator.setSales(mobile_sales)
mobile_warehouse.setThreshold(200)
mobile_purchase.buyStuff(300)
mobile_sales.sellStuff(120)
打印结果如下：
PURCHASE:Bought 300
MEDIATOR:Get Info--buy
WAREHOUSE:Increase 300
MEDIATOR:Get Info--increase
SALES:Get Notice--Inc 300
PURCHASE:Get Notice--Inc 300
SALES:Get Notice--Bought 300
SALES:Sell 120
MEDIATOR:Get Info--sell
WAREHOUSE:Decrease 120
MEDIATOR:Get Info--decrease
SALES:Get Notice--Dec 120
PURCHASE:Get Notice--Dec 120
WAREHOUSE:Warning...Stock is low...
MEDIATOR:Get Info--warning
SALES:Get Notice--Stock is low.180 Left.
PURCHASE:Get Notice--Stock is low. Please Buy More!!! 180 Left
PURCHASE:Get Notice--Sold 120
二、中介者模式
中介者模式的定义为：用一个中介对象封装一系列的对象交互。中介者使各对象不需要显式地互相作用，从而使其耦合松散，并可以独立地改变它们之间的交互。
三、中介者模式的优点和应用场景
优点：
1、减少类与类的依赖，降低了类和类之间的耦合；
2、容易扩展规模。
应用场景：
1、设计类图时，出现了网状结构时，可以考虑将类图设计成星型结构，这样就可以使用中介者模式了。如机场调度系统（多个跑道、飞机、指挥塔之间的调度）、路由系统；著名的MVC框架中，其中的C（Controller）就是M（Model）和V（View）的中介者。
四、中介者模式的缺点
1、中介者本身的复杂性可能会很大，例如，同事类的方法如果很多的话，本例中的execute逻辑会很复杂。
模板模式
一、股票查询客户端
投资股票是种常见的理财方式，我国股民越来越多，实时查询股票的需求也越来越大。今天，我们通过一个简单的股票查询客户端来认识一种简单的设计模式：模板模式。
根据股票代码来查询股价分为如下几个步骤：登录、设置股票代码、查询、展示。构造如下的虚拟股票查询器：
class StockQueryDevice():
stock_code="0"
stock_price=0.0
def login(self,usr,pwd):
pass
def setCode(self,code):
self.stock_code=code
def queryPrice(self):
pass
def showPrice(self):
pass
现在查询机构很多，我们可以根据不同的查询机构和查询方式，来通过继承的方式实现其对应的股票查询器类。例如，WebA和WebB的查询器类可以构造如下：
class WebAStockQueryDevice(StockQueryDevice):
def login(self,usr,pwd):
if usr=="myStockA" and pwd=="myPwdA":
print "Web A:Login OK... user:%s pwd:%s"%(usr,pwd)
return True
else:
print "Web A:Login ERROR... user:%s pwd:%s"%(usr,pwd)
return False
def queryPrice(self):
print "Web A Querying...code:%s "%self.stock_code
self.stock_price=20.00
def showPrice(self):
print "Web A Stock Price...code:%s price:%s"%(self.stock_code,self.stock_price)
class WebBStockQueryDevice(StockQueryDevice):
def login(self,usr,pwd):
if usr=="myStockB" and pwd=="myPwdB":
print "Web B:Login OK... user:%s pwd:%s"%(usr,pwd)
return True
else:
print "Web B:Login ERROR... user:%s pwd:%s"%(usr,pwd)
return False
def queryPrice(self):
print "Web B Querying...code:%s "%self.stock_code
self.stock_price=30.00
def showPrice(self):
print "Web B Stock Price...code:%s price:%s"%(self.stock_code,self.stock_price)
在场景中，想要在网站A上查询股票，需要进行如下操作：
if __name__=="__main__":
web_a_query_dev=WebAStockQueryDevice()
web_a_query_dev.login("myStockA","myPwdA")
web_a_query_dev.setCode("12345")
web_a_query_dev.queryPrice()
web_a_query_dev.showPrice()
打印结果如下：
Web A:Login OK... user:myStockA pwd:myPwdA
Web A Querying...code:12345
Web A Stock Price...code:12345 price:20.0
每次操作，都会调用登录，设置代码，查询，展示这几步，是不是有些繁琐？既然有些繁琐，何不将这几步过程封装成一个接口。由于各个子类中的操作过程基本满足这个流程，所以这个方法可以写在父类中：
class StockQueryDevice():
stock_code="0"
stock_price=0.0
def login(self,usr,pwd):
pass
def setCode(self,code):
self.stock_code=code
def queryPrice(self):
pass
def showPrice(self):
pass
def operateQuery(self,usr,pwd,code):
self.login(usr,pwd)
self.setCode(code)
self.queryPrice()
self.showPrice()
return True
这样，在业务场景中，就可以通过operateQuery一气呵成了。
if __name__=="__main__":
web_a_query_dev=WebAStockQueryDevice()
web_a_query_dev.operateQuery("myStockA","myPwdA","12345")
这种基本每个程序员都会想到的解决方案，就是模板模式。很简单吧。
但也许你会问，登录并不一定每次都会成功呀？是的，所以在operateQuery接口中需要做一重判断，写成：
def operateQuery(self,usr,pwd,code):
if not self.login(usr,pwd):
return False
self.setCode(code)
self.queryPrice()
self.showPrice()
return True
在模板模式中，像这样类似于login等根据特定情况，定制某些特定动作的函数，被称作钩子函数。此例中，如果登录失败（user：myStock B，pwd:myPwdA），会打印如下结果：
Web A:Login ERROR... user:myStockB pwd:myPwdA
二、模板模式
模板模式定义如下：定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定的步骤。子类实现的具体方法叫作基本方法，实现对基本方法高度的框架方法，叫作模板方法。
三、模板模式的优点和应用
优点：
1、可变的部分可以充分扩展，不变的步骤可以充分封装；
2、提取公共代码，减少冗余代码，便于维护；
3、具体过程可以定制，总体流程方便掌控。
使用场景：
1、某超类的子类中有公有的方法，并且逻辑基本相同，可以使用模板模式。必要时可以使用钩子方法约束其行为。具体如本节例子；
2、比较复杂的算法，可以把核心算法提取出来，周边功能在子类中实现。例如，机器学习中的监督学习算法有很多，如决策树、KNN、SVM等，但机器学习的流程大致相同，都包含输入样本、拟合（fit）、预测等过程，这样就可以把这些过程提取出来，构造模板方法，并通过钩子方法控制流程。
四、模板模式的缺点
1、模板模式在抽象类中定义了子类的方法，即子类对父类产生了影响，部分影响了代码的可读性。
迭代器模式
一、迭代器与生成器
今天的主角是迭代器模式。在python中，迭代器并不用举太多的例子，因为python中的迭代器应用实在太多了（不管是python还是其它很多的编程语言中，实际上迭代器都已经纳入到了常用的库或者包中）。而且在当前，也几乎没有人专门去开发一个迭代器，而是直接去使用list、string、set、dict等python可迭代对象，或者直接使用__iter__和next函数来实现迭代器。如下例：
if __name__=="__main__":
lst=["hello Alice","hello Bob","hello Eve"]
lst_iter=iter(lst)
print lst_iter
print lst_iter.next()
print lst_iter.next()
print lst_iter.next()
print lst_iter.next()
打印如下：
hello Alice
hello Bob
hello Eve
Traceback (most recent call last):
File "D:/WorkSpace/Project/PyDesignMode/example.py", line 719, in
print lst_iter.next()
StopIteration
在这种迭代器的使用过程中，如果next超过了迭代范围，会抛出异常。
在python对象的方法中，也可以轻易使用迭代器模式构造可迭代对象，如下例：
class MyIter(object):
def __init__(self, n):
self.index = 0
self.n = n
def __iter__(self):
return self
def next(self):
if self.index < self.n:
value = self.index**2
self.index += 1
return value
else:
raise StopIteration()
__iter__和next实现了迭代器最基本的方法。如下方式进行调用：
if __name__=="__main__":
x_square=MyIter(10)
for x in x_square:
print x
打印如下：
0
1
4
9
16
25
36
49
64
81
注意__iter__方法中的返回值，由于直接返回了self，因而该迭代器是无法重复迭代的，如以下业务场景：
if __name__=="__main__":
x_square=MyIter(10)
for x in x_square:
print x
for x in x_square:
print x
只能打印一遍平方值。解决办法是，在__iter__中不返回实例，而再返回一个对象，写成：
def __iter__(self):
return MyIter(self.n)
这样，在每次迭代时都可以将迭代器“初始化”，就可以多次迭代了。
另外，在python中，使用生成器可以很方便的支持迭代器协议。生成器通过生成器函数产生，生成器函数可以通过常规的def语句来定义，但是不用return返回，而是用yield一次返回一个结果，在每个结果之间挂起和继续它们的状态，来自动实现迭代协议。
如下例：
def MyGenerater(n):
index=0
while index<n:
yield index**2
index+=1
注意，这是个函数。在每次调用生成器，得到返回结果后，现场得以保留，下次再调用该生 成器时，返回保留的现场从yield后继续执行程序。
if __name__=="__main__":
x_square=MyGenerater(10)
for x in x_square:
print x
打印结果与上面一致。
二、迭代器模式
迭代器模式的定义如下：它提供一种方法，访问一个容器对象中各个元素，而又不需要暴露对象的内部细节。
访问者模式
一、药房业务系统
假设一个药房，有一些大夫，一个药品划价员和一个药房管理员，它们通过一个药房管理系统组织工作流程。大夫开出药方后，药品划价员确定药品是否正常，价格是否正确；通过后药房管理员进行开药处理。该系统可以如何实现？最简单的想法，是分别用一个一个if…else…把划价员处理流程和药房管理流程实现，这样做的问题在于，扩展性不强，而且单一性不强，一旦有新药的加入或者划价流程、开药流程有些变动，会牵扯比较多的改动。今天介绍一种解决这类问题的模式：访问者模式。
首先，构造药品类和工作人员类：
class Medicine:
name=""
price=0.0
def __init__(self,name,price):
self.name=name
self.price=price
def getName(self):
return self.name
def setName(self,name):
self.name=name
def getPrice(self):
return self.price
def setPrice(self,price):
self.price=price
def accept(self,visitor):
pass
class Antibiotic(Medicine):
def accept(self,visitor):
visitor.visit(self)
class Coldrex(Medicine):
def accept(self,visitor):
visitor.visit(self)
药品类中有两个子类，抗生素和感冒药；
class Visitor:
name=""
def setName(self,name):
self.name=name
def visit(self,medicine):
pass
class Charger(Visitor):
def visit(self,medicine):
print "CHARGE: %s lists the Medicine %s. Price:%s " % (self.name,medicine.getName(),medicine.getPrice())
class Pharmacy(Visitor):
def visit(self,medicine):
print "PHARMACY:%s offers the Medicine %s. Price:%s" % (self.name,medicine.getName(),medicine.getPrice())
工作人员分为划价员和药房管理员。
在药品类中，有一个accept方法，其参数是个visitor；而工作人员就是从Visitor类中继承而来的，也就是说，他们就是Visitor，都包含一个visit方法，其参数又恰是medicine。药品作为处理元素，依次允许（Accept）Visitor对其进行操作，这就好比是一条流水线上的一个个工人，对产品进行一次次的加工。整个业务流程还差一步，即药方类的构建（流水线大机器）。
class ObjectStructure:
pass
class Prescription(ObjectStructure):
medicines=[]
def addMedicine(self,medicine):
self.medicines.append(medicine)
def rmvMedicine(self,medicine):
self.medicines.append(medicine)
def visit(self,visitor):
for medc in self.medicines:
medc.accept(visitor)
药方类将待处理药品进行整理，并组织Visitor依次处理。
业务代码如下：
if __name__=="__main__":
yinqiao_pill=Coldrex("Yinqiao Pill",2.0)
penicillin=Antibiotic("Penicillin",3.0)
doctor_prsrp=Prescription()
doctor_prsrp.addMedicine(yinqiao_pill)
doctor_prsrp.addMedicine(penicillin)
charger=Charger()
charger.setName("Doctor Strange")
pharmacy=Pharmacy()
pharmacy.setName("Doctor Wei")
doctor_prsrp.visit(charger)
doctor_prsrp.visit(pharmacy)
打印如下：
CHARGE: Doctor Strange lists the Medicine Yinqiao Pill. Price:2.0
CHARGE: Doctor Strange lists the Medicine Penicillin. Price:3.0
PHARMACY:Doctor Wei offers the Medicine Yinqiao Pill. Price:2.0
PHARMACY:Doctor Wei offers the Medicine Penicillin. Price:3.0
二、访问者模式
访问者模式的定义如下：封装一些作用于某种数据结构中的各元素的操作，它可以在不改变数据结构的前提下定义于作用于这些元素的新操作。
提到访问者模式，就不得不提一下双分派。分派分为静态分派和动态分派。首先解释下静态分派，静态分派即根据请求者的名称和接收到的参数，决定多态时处理的操作。比如在Java或者C++中，定义名称相同但参数不同的函数时，会根据最终输入的参数来决定调用哪个函数。双分派顾名思义，即最终的操作决定于两个接收者的类型，在本例中，药品和工作人员互相调用了对方（药品的accept和工作人员的visit中，对方都是参数），就是双分派的一种应用。
那么Python支持静态分派么？先看下面的一个例子。
def max_num(x,y,z):
return max(max(x,y),z)
def max_num(x,y):
return max(x,y)
if __name__=="__main__":
print max_num(1,2,4)
打印如下：
Traceback (most recent call last):
File "D:/WorkSpace/Project/PyDesignMode/example.py", line 786, in
print max_num(1,2,4)
TypeError: max_num() takes exactly 2 arguments (3 given)
可见，Python原生是不支持静态分派的，因而也不直接支持更高层次的分派。访问者模式实现的分派，是一种动态双分派。但这并不妨碍Python通过访问者模式实现一种基于类的“双分派效果”。Python多分派可以参考David Mertz 博士的一篇文章：可爱的Python：多分派—用多元法泛化多样性。
三、访问者模式的优点和应用场景
优点：
1、将不同的职责非常明确地分离开来，符合单一职责原则；
2、职责的分开也直接导致扩展非常优良，灵活性非常高，加减元素和访问者都非常容易。
应用场景：
1、要遍历不同的对象，根据对象进行不同的操作的场景；或者一个对象被多个不同对象顺次处理的情况，可以考虑使用访问者模式。除本例外，报表生成器也可以使用访问者模式实现，报表的数据源由多个不同的对象提供，每个对象都是Visitor，报表这个Element顺次Accept各访问者完善并生成对象。
四、访问者模式的缺点
1、访问者得知了元素细节，与最小隔离原则相悖；
2、元素变更依旧可能引起Visitor的修改。
观察者模式
一、火警报警器
在门面模式中，我们提到过火警报警器。在当时，我们关注的是通过封装减少代码重复。而今天，我们将从业务流程的实现角度，来再次实现该火警报警器。
class AlarmSensor:
def run(self):
print "Alarm Ring..."
class WaterSprinker:
def run(self):
print "Spray Water..."
class EmergencyDialer:
def run(self):
print "Dial 119..."
以上是门面模式中的三个传感器类的结构。仔细分析业务，报警器、洒水器、拨号器都是“观察”烟雾传感器的情况来做反应的。因而，他们三个都是观察者，而烟雾传感器则是被观察对象了。根据分析，将三个类提取共性，泛化出“观察者”类，并构造被观察者。
观察者如下：
class Observer:
def update(self):
pass
class AlarmSensor(Observer):
def update(self,action):
print "Alarm Got: %s" % action
self.runAlarm()
def runAlarm(self):
print "Alarm Ring..."
class WaterSprinker(Observer):
def update(self,action):
print "Sprinker Got: %s" % action
self.runSprinker()
def runSprinker(self):
print "Spray Water..."
class EmergencyDialer(Observer):
def update(self,action):
print "Dialer Got: %s"%action
self.runDialer()
def runDialer(self):
print "Dial 119..."
观察者中定义了update接口，如果被观察者状态比较多，或者每个具体的观察者方法比较多，可以通过update传参数进行更丰富的控制。
下面构造被观察者。
class Observed:
observers=[]
action=""
def addObserver(self,observer):
self.observers.append(observer)
def notifyAll(self):
for obs in self.observers:
obs.update(self.action)
class smokeSensor(Observed):
def setAction(self,action):
self.action=action
def isFire(self):
return True
被观察者中首先将观察对象加入到观察者数组中，若发生情况，则通过notifyAll通知各观察者。
业务代码如下：
if __name__=="__main__":
alarm=AlarmSensor()
sprinker=WaterSprinker()
dialer=EmergencyDialer()
smoke_sensor=smokeSensor()
smoke_sensor.addObserver(alarm)
smoke_sensor.addObserver(sprinker)
smoke_sensor.addObserver(dialer)
if smoke_sensor.isFire():
smoke_sensor.setAction("On Fire!")
smoke_sensor.notifyAll()
打印如下：
Alarm Got: On Fire!
Alarm Ring...
Sprinker Got: On Fire!
Spray Water...
Dialer Got: On Fire!
Dial 119...
二、观察者模式
观察者模式也叫发布-订阅模式，其定义如下：定义对象间一种一对多的依赖关系，使得当该对象状态改变时，所有依赖于它的对象都会得到通知，并被自动更新。
观察者模式的通知方式可以通过直接调用等同步方式实现（如函数调用，HTTP接口调用等），也可以通过消息队列异步调用（同步调用指被观察者发布消息后，必须等所有观察者响应结束后才可以进行接下来的操作；异步调用指被观察者发布消息后，即可进行接下来的操作。）。事实上，许多开源的消息队列就直接支持发布-订阅模式，如Zero MQ等。
三、观察者模式的优点和应用场景
优点：
1、观察者与被观察者之间是抽象耦合的；
2、可以将许多符合单一职责原则的模块进行触发，也可以很方便地实现广播。
应用场景：
1、消息交换场景。如上述说到的消息队列等；
2、多级触发场景。比如支持中断模式的场景中，一个中断即会引发一连串反应，就可以使用观察者模式。
四、观察者模式的缺点
1、观察者模式可能会带来整体系统效率的浪费；
2、如果被观察者之间有依赖关系，其逻辑关系的梳理需要费些心思。
解释器模式
一、模拟吉他
要开发一个自动识别谱子的吉他模拟器，达到录入谱即可按照谱发声的效果。除了发声设备外（假设已完成），最重要的就是读谱和译谱能力了。分析其需求，整个过程大致上分可以分为两部分：根据规则翻译谱的内容；根据翻译的内容演奏。我们用一个解释器模型来完成这个功能。
class PlayContext():
play_text = None
class Expression():
def interpret(self, context):
if len(context.play_text) == 0:
return
else:
play_segs=context.play_text.split(" ")
for play_seg in play_segs:
pos=0
for ele in play_seg:
if ele.isalpha():
pos+=1
continue
break
play_chord = play_seg[0:pos]
play_value = play_seg[pos:]
self.execute(play_chord,play_value)
def execute(self,play_key,play_value):
pass
class NormGuitar(Expression):
def execute(self, key, value):
print "Normal Guitar Playing--Chord:%s Play Tune:%s"%(key,value)
PlayContext类为谱的内容，这里仅含一个字段，没有方法。Expression即表达式，里面仅含两个方法，interpret负责转译谱，execute则负责演奏；NormGuitar类覆写execute，以吉他 的方式演奏。
业务场景如下：
if __name__=="__main__":
context = PlayContext()
context.play_text = "C53231323 Em43231323 F43231323 G63231323"
guitar=NormGuitar()
guitar.interpret(context)
打印如下：
Normal Guitar Playing--Chord:C Play Tune:53231323
Normal Guitar Playing--Chord:Em Play Tune:43231323
Normal Guitar Playing--Chord:F Play Tune:43231323
Normal Guitar Playing--Chord:G Play Tune:63231323
二、解释器模式
解释器模式定义如下：给定一种语言，定义它的文法表示，并定义一个解释器，该解释器使用该表示来解释语言中的句子。典型的解释器模式中会有终结符和非终结符之说，语法也根据两种终结符，决定语句最终含义。上例中，非终结符就是空格，终结符就是整个句尾。
三、解释器模式的优点和应用场景
优点：
1、在语法分析的场景中，具有比较好的扩展性。规则修改和制订比较灵活。
应用场景：
1、若一个问题重复发生，可以考虑使用解释器模式。这点在数据处理和日志处理过程中使用较多，当数据的需求方需要将数据纳为己用时，必须将数据“翻译”成本系统的数据规格；同样的道理，日志分析平台也需要根据不同的日志格式翻译成统一的“语言”。
2、特定语法解释器。如各种解释型语言的解释器，再比如自然语言中基于语法的文本分析等。
四、解释器模式的缺点
1、解释规则多样化会导致解释器的爆炸；
2、解释器目标比较单一，行为模式比较固定，因而重要的模块中尽量不要使用解释器模式。
备忘录模式
一、游戏进度保存
打过游戏的朋友一定知道，大多数游戏都有保存进度的功能，如果一局游戏下来，忘保存了进度，那么下次只能从上次进度点开始重新打了。一般情况下，保存进度是要存在可持久化存储器上，本例中先以保存在内存中来模拟实现该场景的情形。
以模拟一个战斗角色为例。首先，创建游戏角色。
class GameCharacter():
vitality = 0
attack = 0
defense = 0
def displayState(self):
print 'Current Values:'
print 'Life:%d' % self.vitality
print 'Attack:%d' % self.attack
print 'Defence:%d' % self.defense
def initState(self,vitality,attack,defense):
self.vitality = vitality
self.attack = attack
self.defense = defense
def saveState(self):
return Memento(self.vitality, self.attack, self.defense)
def recoverState(self, memento):
self.vitality = memento.vitality
self.attack = memento.attack
self.defense = memento.defense
class FightCharactor(GameCharacter):
def fight(self):
self.vitality -= random.randint(1,10)
GameCharacter定义了基本的生命值、攻击值、防御值以及实现角色状态控制的方法，FightCharactor实现具体的“战斗”接口。为实现保存进度的细节，还需要一个备忘录，来保存进度。
class Memento:
vitality = 0
attack = 0
defense = 0
def __init__(self, vitality, attack, defense):
self.vitality = vitality
self.attack = attack
self.defense = defense
万事俱备，在业务逻辑中可以进行类的调度了。
if __name__=="__main__":
game_chrctr = FightCharactor()
game_chrctr.initState(100,79,60)
game_chrctr.displayState()
memento = game_chrctr.saveState()
game_chrctr.fight()
game_chrctr.displayState()
game_chrctr.recoverState(memento)
game_chrctr.displayState()
打印如下：
Current Values:
Life:100
Attack:79
Defence:60
Current Values:
Life:91
Attack:79
Defence:60
Current Values:
Life:100
Attack:79
Defence:60
由生命值变化可知，先保存状态值，经过一轮打斗后，生命值由100变为91，而后恢复状态值，生命值又恢复成100。
二、备忘录模式
备忘录模式定义如下：在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可以将该对象恢复到原来保存的状态。在备忘录模式中，如果要保存的状态多，可以创造一个备忘录管理者角色来管理备忘录。
三、备忘录模式应用场景
1、需要保存和恢复数据的相关状态场景。如保存游戏状态的场景；撤销场景，如Ctrl-Z操作；事务回滚的应用。一般情况下事务回滚有两种方式：一是把从恢复点开始的操作都反向执行一遍；二是直接恢复到恢复点的各种状态。两种方式各有优缺点，要结合业务场景，决定使用哪种模式；
2、副本监控场景。备忘录可以当作一个临时的副本监控，实现非实时和准实时的监控。
状态模式
一、电梯控制器
电梯在我们周边随处可见，电梯的控制逻辑中心是由电梯控制器实现的。电梯的控制逻辑，即使简单点设计，把状态分成开门状态，停止状态和运行状态，操作分成开门、关门、运行、停止，那流程也是很复杂的。首先，开门状态不能开门、运行、停止；停止状态不能关门，停止；运行状态不能开门、关门、运行。要用一个一个if…else…实现，首先代码混乱，不易维护；二是不易扩展。至于各种设计原则什么的……
那该如何实现？在上边的逻辑中，每个操作仅仅是一个操作，状态切换与操作是分离的，这也造成后来操作和状态“相互配合”的“手忙脚乱”。如果把状态抽象成一个类，每个状态为一个子类，每个状态实现什么操作，不实现什么操作，仅仅在这个类中具体实现就可以了。
下面我们实现这个逻辑。
先实现抽象的状态类：
class LiftState:
def open(self):
pass
def close(self):
pass
def run(self):
pass
def stop(self):
pass
而后实现各个具体的状态类：
class OpenState(LiftState):
def open(self):
print "OPEN:The door is opened..."
return self
def close(self):
print "OPEN:The door start to close..."
print "OPEN:The door is closed"
return StopState()
def run(self):
print "OPEN:Run Forbidden."
return self
def stop(self):
print "OPEN:Stop Forbidden."
return self
class RunState(LiftState):
def open(self):
print "RUN:Open Forbidden."
return self
def close(self):
print "RUN:Close Forbidden."
return self
def run(self):
print "RUN:The lift is running..."
return self
def stop(self):
print "RUN:The lift start to stop..."
print "RUN:The lift stopped..."
return StopState()
class StopState(LiftState):
def open(self):
print "STOP:The door is opening..."
print "STOP:The door is opened..."
return OpenState()
def close(self):
print "STOP:Close Forbidden"
return self
def run(self):
print "STOP:The lift start to run..."
return RunState()
def stop(self):
print "STOP:The lift is stopped."
return self
为在业务中调度状态转移，还需要将上下文进行记录，需要一个上下文的类。
class Context:
lift_state=""
def getState(self):
return self.lift_state
def setState(self,lift_state):
self.lift_state=lift_state
def open(self):
self.setState(self.lift_state.open())
def close(self):
self.setState(self.lift_state.close())
def run(self):
self.setState(self.lift_state.run())
def stop(self):
self.setState(self.lift_state.stop())
这样，在进行电梯的调度时，只需要调度Context就可以了。业务逻辑中如下所示：
if __name__=="__main__":
ctx = Context()
ctx.setState(StopState())
ctx.open()
ctx.run()
ctx.close()
ctx.run()
ctx.stop()
打印如下：
STOP:The door is opening...
STOP:The door is opened...
OPEN:Run Forbidden.
OPEN:The door start to close...
OPEN:The dorr is closed
STOP:The lift start to run...
RUN:The lift start to stop...
RUN:The lift stopped...
由逻辑中可知，电梯先在STOP状态，然后开门，开门时运行Run，被禁止，然后，关门、运行、停止。
二、状态模式
状态模式的定义如下：当一个对象内在状态改变时允许其改变行为，这个对象看起来像改变了其类。
三、状态模式的优点和应用场景
优点：
1、状态模式的优点是结构清晰，相比于if…else…简约了不少；
2、封装性好，外部调用不必知道内部实现细节。
应用场景：
1、行为状态改变的场景。这点在各种控制器中非常常见，同时，逻辑结构为状态转移图的场景中都非常适用。
四、状态模式的缺点
1、在状态比较多时，子类也会非常多，不便于管理。