Python的23种设计模式(完整版带源码实例)

作者：虚坏叔叔
博客：https://xuhss.com

早餐店不会开到晚上，想吃的人早就来了！😄

一 什么是设计模式

设计模式是面对各种问题进行提炼和抽象而形成的解决方案。这些设计方案是前人不断试验，考虑了封装性、复用性、效率、可修改、可移植等各种因素的高度总结。它不限于一种特定的语言，它是一种解决问题的思想和方法

二 为什么要有设计模式

公司人事会有变动，程序员也会成长。不管是哪种情况，代码非常有可能会被移交，即代码的编写者和维护者很有可能会是不同的人。那么代码的可读性就显得非常重要了。由于高级语言的出现，让机器读懂你的意图已经不是最主要的“矛盾”，而让人读懂你的意图才是最重要。按照设计模式编写的代码，其可读性也会大大提升，利于团队项目的继承和扩展

三 有那些设计模式

设计模式可以分为三个大类： 创建类设计模式、结构类设计模式、行为类设计模式

创建类设计模式（5种）

单例模式、工厂模式（简单工厂模式、抽象工厂模式）、建造者模式、原型模式

结构类设计模式（7种）

代理模式、装饰器模式、适配器模式、门面模式、组合模式、享元模式、桥梁模式

行为类设计模式（11种）

策略模式、责任链模式、命令模式、中介者模式、模板模式、迭代器模式、访问者模式、观察者模式、解释器模式、备忘录模式、状态模式
设计模式也衍生出了很多的新的种类，不局限于这23种

四 设计模式与架构，框架的关系

1 软件框架与设计模式的关系

软件框架随着软件工程的发展而出现，所谓的软件框架，是提取了特定领域的软件的共性部分所形成的软件体系，它并不是一个成熟的软件，而更像是一个“半成品”，程序员在框架之上，可以很方便地某些特定领域实现又快又可靠的二次开发。
设计模式 和 软件框架 在软件设计中是两个 不同 的研究领域：
A、设计模式如前边的定义所讲，它指的是针对一类问题的解决方法，一个设计模式可应用于不同的框架和被不同的语言所实现；而框架则是一个应用的体系结构，是一种或多种设计模式和代码的混合体；
B、设计模式相较于框架更容易移植，并且可以用各种语言实现，而软件框架则受限于领域大环境。虽然设计模式和软件框架有很多不同，但在某些方面他们二者是统一的，即重视软件复用，提高开发效率。

2 软件架构与设计模式的关系

软件架构是个比较大的概念，架构要考虑软件的整体结构、层次划分以及不同部分间的协作和交互等，架构的着眼点偏整体。
相比之下，框架和设计模式的范围则具体很多，框架着眼于领域内的解决方法，而设计模式则针对一类问题的解决方案和设计思路。
总体来说，软件架构可以由不同的框架和不同的设计模式，再加上特定的构件组合来实现；框架可以根据设计模式结合特定编程语言和环境来实现。设计模式就是解决单一问题的设计思路和解决方法。

一、总线

总线是计算机各种功能部件或者设备之间传送数据、控制信号等信息的公共通信解决方案之一。
现假设有如下场景：某中央处理器（CPU）通过某种协议总线与一个信号灯相连，信号灯有64种颜色可以设置，中央处理器上运行着三个线程，都可以对这个信号灯进行控制，并且可以独立设置该信号灯的颜色。
抽象掉协议细节（用打印表示），如何实现线程对信号等的控制逻辑。
加线程锁进行控制，无疑是最先想到的方法，但各个线程对锁的控制，无疑加大了模块之间的耦合。下面，我们就用设计模式中的单例模式，来解决这个问题。
什么是单例模式？单例模式是指：保证一个类仅有一个实例，并提供一个访问它的全局访问点。
具体到此例中，总线对象，就是一个单例，它仅有一个实例，各个线程对总线的访问只有一个全局访问点，即惟一的实例。
Python代码如下：

import threadingimport timeclass Singleton(object):      def __new__(cls, *args, **kw):        if not hasattr(cls, '_instance'):            orig = super(Singleton, cls)            cls._instance = orig.__new__(cls, *args, **kw)        return cls._instanceclass Bus(Singleton):    lock = threading.RLock()    def sendData(self, data):        self.lock.acquire()        time.sleep(3)        print("Sending Signal Data...", data)        self.lock.release()class VisitEntity(threading.Thread):    my_bus = ""    name = ""    def getName(self):        return self.name    def setName(self, name):        self.name = name    def run(self):        self.my_bus = Bus()        self.my_bus.sendData(self.name)if __name__ == "__main__":    for i in range(3):        print("Entity %d begin to run..." % i)        my_entity = VisitEntity()        my_entity.setName("Entity_"+str(i))        my_entity.start()

运行结果如下：

Entity 0 begin to run...Entity 1 begin to run...Entity 2 begin to run...Sending Signal Data... Entity_0Sending Signal Data... Entity_1Sending Signal Data... Entity_2

在程序运行过程中，三个线程同时运行（运行结果的前三行先很快打印出来），而后分别占用总线资源（后三行每隔3秒打印一行）。虽然看上去总线Bus被实例化了三次，但实际上在内存里只有一个实例。

二、单例模式

单例模式是所有设计模式中比较简单的一类，其定义如下：Ensure a class has only one instance, and provide a global point of access to it.（保证某一个类只有一个实例，而且在全局只有一个访问点）

三、单例模式的优点和应用

单例模式的优点

由于单例模式要求在全局内只有一个实例，因而可以节省比较多的内存空间；
2、全局只有一个接入点，可以更好地进行数据同步控制，避免多重占用；3、单例可长驻内存，减少系统开销。

单例模式的应用举例

生成全局惟一的序列号；
2、访问全局复用的惟一资源，如磁盘、总线等；
3、单个对象占用的资源过多，如数据库等；
4、系统全局统一管理，如Windows下的Task Manager；
5、网站计数器。

四、单例模式的缺点

单例模式的扩展是比较困难的；
2、赋于了单例以太多的职责，某种程度上违反单一职责原则（六大原则后面会讲到）;
3、单例模式是并发协作软件模块中需要最先完成的，因而其不利于测试；4、单例模式在某种情况下会导致“资源瓶颈”。

一、快餐点餐系统

想必大家一定见过类似于麦当劳自助点餐台一类的点餐系统吧。在一个大的触摸显示屏上，有三类可以选择的上餐品：汉堡等主餐、小食、饮料。当我们选择好自己需要的食物，支付完成后，订单就生成了。下面，我们用今天的主角–工厂模式–来生成这些食物的逻辑主体。首先，来看主餐的生成（仅以两种汉堡为例）。

class Burger():    name = ""    price = 0.0    def getPrice(self):        return self.price    def setPrice(self, price):        self.price = price    def getName(self):        return self.nameclass cheeseBurger(Burger):    def __init__(self):        self.name = "cheese burger"        self.price = 10.0class spicyChickenBurger(Burger):    def __init__(self):        self.name = "spicy chicken burger"        self.price = 15.0

其次，是小食。（内容基本一致）

class Snack():    name = ""    price = 0.0    type = "SNACK"    def getPrice(self):        return self.price    def setPrice(self, price):        self.price = price    def getName(self):        return self.nameclass chips(Snack):    def __init__(self):        self.name = "chips"        self.price = 6.0class chickenWings(Snack):    def __init__(self):        self.name = "chicken wings"        self.price = 12.0

最后，是饮料。

class Beverage():    name = ""    price = 0.0    type = "BEVERAGE"    def getPrice(self):        return self.price    def setPrice(self, price):        self.price = price    def getName(self):        return self.nameclass coke(Beverage):    def __init__(self):        self.name = "coke"        self.price = 4.0class milk(Beverage):    def __init__(self):        self.name = "milk"        self.price = 5.0

以上的Burger，Snack，Beverage，都可以认为是该快餐店的产品，由于只提供了抽象方法，我们把它们叫抽象产品类，而cheese burger等6个由抽象产品类衍生出的子类，叫作具体产品类。 接下来，“工厂”就要出现了。

class foodFactory():    type = ""    def createFood(self, foodClass):        print self.type, " factory produce a instance."        foodIns = foodClass()        return foodInsclass burgerFactory(foodFactory):    def __init__(self):        self.type = "BURGER"class snackFactory(foodFactory):    def __init__(self):        self.type = "SNACK"class beverageFactory(foodFactory):    def __init__(self):        self.type = "BEVERAGE"

同样，foodFactory为抽象的工厂类，而burgerFactory，snackFactory，beverageFactory为具体的工厂类。在业务场景中，工厂模式是如何“生产”产品的呢？

if __name__ == "__main__":    burger_factory = burgerFactory()    snack_factorry = snackFactory()    beverage_factory = beverageFactory()    cheese_burger = burger_factory.createFood(cheeseBurger)    print (cheese_burger.getName(), cheese_burger.getPrice())    chicken_wings = snack_factorry.createFood(chickenWings)    print (chicken_wings.getName(), chicken_wings.getPrice())    coke_drink = beverage_factory.createFood(coke)    print (coke_drink.getName(), coke_drink.getPrice())

可见，业务中先生成了工厂，然后用工厂中的createFood方法和对应的参数直接生成产品实例。打印结果如下：BURGER factory produce a instance.cheese burger 10.0SNACK factory produce a instance.chicken wings 12.0BEVERAGE factory produce a instance.coke 4.0

二、工厂模式、简单工厂模式、抽象工厂模式

工厂模式的定义如下：定义一个用于创建对象的接口，让子类决定实例化哪个类。工厂方法使一个类的实例化延迟到其子类。其通用类图如下。其产品类定义产品的公共属性和接口，工厂类定义产品实例化的“方式”。

)

在上述例子中，工厂在使用前必须实例化。如果，把工厂加个类方法，写成如下形式：

class simpleFoodFactory():    @classmethod    def createFood(cls,foodClass):        print "Simple factory produce a instance."        foodIns = foodClass()        return foodIns

在场景中写成如下形式：spicy_chicken_burger=simpleFoodFactory.createFood(spicyChickenBurger)这样，省去了将工厂实例化的过程。这种模式就叫做简单工厂模式。还是在上述例子中，createFood方法中必须传入foodClass才可以指定生成的food实例种类，如果，将每一个细致的产品都建立对应的工厂（如cheeseBurger建立对应一个cheeseBurgerFactory），这样，生成食物时，foodClass也不必指定。事实上，此时，burgerFactory就是具体食物工厂的一层抽象。这种模式，就是抽象工厂模式。

三、工厂模式的优点和应用

工厂模式、抽象工厂模式的优点：
1、工厂模式巨有非常好的封装性，代码结构清晰；在抽象工厂模式中，其结构还可以随着需要进行更深或者更浅的抽象层级调整，非常灵活；
2、屏蔽产品类，使产品的被使用业务场景和产品的功能细节可以分而开发进行，是比较典型的解耦框架。
工厂模式、抽象工厂模式的使用场景：
1、当系统实例要求比较灵活和可扩展时，可以考虑工厂模式或者抽象工厂模式实现。比如，在通信系统中，高层通信协议会很多样化，同时，上层协议依赖于下层协议，那么就可以对应建立对应层级的抽象工厂，根据不同的“产品需求”去生产定制的实例。

四、工厂类模式的不足

工厂模式相对于直接生成实例过程要复杂一些，所以，在小项目中，可以不使用工厂模式；
2、抽象工厂模式中，产品类的扩展比较麻烦。毕竟，每一个工厂对应每一类产品，产品扩展，就意味着相应的抽象工厂也要扩展

一、快餐点餐系统

今天的例子，还是上一次谈到的快餐点餐系统。只不过，今天我们从订单的角度来构造这个系统。最先还是有请上次的主角们： 主餐：

class Burger():    name=""    price=0.0    def getPrice(self):        return self.price    def setPrice(self,price):        self.price=price    def getName(self):        return self.nameclass cheeseBurger(Burger):    def __init__(self):        self.name="cheese burger"        self.price=10.0class spicyChickenBurger(Burger):    def __init__(self):        self.name="spicy chicken burger"        self.price=15.0

小食：

class Snack():    name = ""    price = 0.0    type = "SNACK"    def getPrice(self):        return self.price    def setPrice(self, price):        self.price = price    def getName(self):        return self.nameclass chips(Snack):    def __init__(self):        self.name = "chips"        self.price = 6.0class chickenWings(Snack):    def __init__(self):        self.name = "chicken wings"        self.price = 12.0

饮料：

class Beverage():    name = ""    price = 0.0    type = "BEVERAGE"    def getPrice(self):        return self.price    def setPrice(self, price):        self.price = price    def getName(self):        return self.nameclass coke(Beverage):    def __init__(self):        self.name = "coke"        self.price = 4.0class milk(Beverage):    def __init__(self):        self.name = "milk"        self.price = 5.0

最终，我们是要建造一个订单，因而，需要一个订单类。假设，一个订单，包括一份主食，一份小食，一种饮料。（省去一些异常判断）

class order():    burger=""    snack=""    beverage=""    def __init__(self,orderBuilder):        self.burger=orderBuilder.bBurger        self.snack=orderBuilder.bSnack        self.beverage=orderBuilder.bBeverage    def show(self):        print "Burger:%s"%self.burger.getName()        print "Snack:%s"%self.snack.getName()        print "Beverage:%s"%self.beverage.getName()

代码中的orderBuilder是什么鬼？这个orderBuilder就是建造者模式中所谓的“建造者”了，先不要问为什么不在order类中把所有内容都填上，而非要用builder去创建。接着往下看。 orderBuilder的实现如下 ：

class orderBuilder():    bBurger=""    bSnack=""    bBeverage=""    def addBurger(self,xBurger):        self.bBurger=xBurger    def addSnack(self,xSnack):        self.bSnack=xSnack    def addBeverage(self,xBeverage):        self.bBeverage=xBeverage    def build(self):        return order(self)

在场景中如下去实现订单的生成：

if  __name__=="__main__":    order_builder=orderBuilder()    order_builder.addBurger(spicyChickenBurger())    order_builder.addSnack(chips())    order_builder.addBeverage(milk())    order_1=order_builder.build()    order_1.show()

打印结果如下：Burger:spicy chicken burgerSnack:chipsBeverage:milk

二、建造者模式

建造者模式的定义如下：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式的作用，就是将“构建”和“表示”分离，以达到解耦的作用。在上面订单的构建过程中，如果将order直接通过参数定义好（其构建与表示没有分离），同时在多处进行订单生成，此时需要修改订单内容，则需要一处处去修改，业务风险也就提高了不少。在建造者模式中，还可以加一个Director类，用以安排已有模块的构造步骤。对于在建造者中有比较严格的顺序要求时，该类会有比较大的用处。在上述例子中，Director实现如下：

class orderDirector():    order_builder=""    def __init__(self,order_builder):        self.order_builder=order_builder    def createOrder(self,burger,snack,beverage):        self.order_builder.addBurger(burger)        self.order_builder.addSnack(snack)        self.order_builder.addBeverage(beverage)        return self.order_builder.build()

通过createOrder直接代入参数，即可直接生成订单。

三、建造者模式的优点和使用场景

优点：

封装性好，用户可以不知道对象的内部构造和细节，就可以直接建造对象；2、系统扩展容易；3、建造者模式易于使用，非常灵活。在构造性的场景中很容易实现“流水线”；4、便于控制细节。

使用场景：

目标对象由组件构成的场景中，很适合建造者模式。例如，在一款赛车游戏中，车辆生成时，需要根据级别、环境等，选择轮胎、悬挂、骨架等部件，构造一辆“赛车”；2、在具体的场景中，对象内部接口需要根据不同的参数而调用顺序有所不同时，可以使用建造者模式。例如：一个植物养殖器系统，对于某些不同的植物，浇水、施加肥料的顺序要求可能会不同，因而可以在Director中维护一个类似于队列的结构，在实例化时作为参数代入到具体建造者中。

四、建造者模式的缺点

“加工工艺”对用户不透明。（封装的两面性）

一、图层

大家如果用过类似于Photoshop的平面设计软件，一定都知道图层的概念。图层概念的提出，使得设计、图形修改等操作更加便利。设计师既可以修改和绘制当前图像对象，又可以保留其它图像对象，逻辑清晰，且可以及时得到反馈。本节内容，将以图层为主角，介绍原型模式。首先，设计一个图层对象。

class simpleLayer:    background=[0,0,0,0]    content="blank"    def getContent(self):        return self.content    def getBackgroud(self):        return self.background    def paint(self,painting):        self.content=painting    def setParent(self,p):        self.background[3]=p    def fillBackground(self,back):        self.background=back

在实际的实现中，图层实现会很复杂，这里仅介绍相关的设计模式，做了比较大的抽象，用background表示背景的RGBA，简单用content表示内容，除了直接绘画，还可以设置透明度。新建图层，填充蓝底并画一只狗，可以简单表示如下：

if  __name__=="__main__":    dog_layer=simpleLayer()    dog_layer.paint("Dog")    dog_layer.fillBackground([0,0,255,0])    print "Background:",dog_layer.getBackgroud()    print "Painting:",dog_layer.getContent()

**打印如下：**Background: [0, 0, 255, 0]Painting: Dog
接下来，如果需要再生成一个同样的图层，再填充同样的颜色，再画一只同样狗，该如何做呢？还是按照新建图层、填充背景、画的顺序么？或许你已经发现了，这里可以用复制的方法来实现，而复制（clone）这个动作，就是原型模式的精髓了。按照此思路，在图层类中新加入两个方法：clone和deep_clone

from copy import copy, deepcopyclass simpleLayer:    background=[0,0,0,0]    content="blank"    def getContent(self):        return self.content    def getBackgroud(self):        return self.background    def paint(self,painting):        self.content=painting    def setParent(self,p):        self.background[3]=p    def fillBackground(self,back):        self.background=back    def clone(self):        return copy(self)    def deep_clone(self):        return deepcopy(self)if  __name__=="__main__":    dog_layer=simpleLayer()    dog_layer.paint("Dog")    dog_layer.fillBackground([0,0,255,0])    print "Background:",dog_layer.getBackgroud()    print "Painting:",dog_layer.getContent()    another_dog_layer=dog_layer.clone()    print "Background:", another_dog_layer.getBackgroud()    print "Painting:", another_dog_layer.getContent()

打印结果如下：Background: [0, 0, 255, 0]Painting: DogBackground: [0, 0, 255, 0]Painting: Dog
clone和deep_clone有什么区别呢？大多数编程语言中，都会涉及到深拷贝和浅拷贝的问题，一般来说，浅拷贝会拷贝对象内容及其内容的引用或者子对象的引用，但不会拷贝引用的内容和子对象本身；而深拷贝不仅拷贝了对象和内容的引用，也会拷贝引用的内容。所以，一般深拷贝比浅拷贝复制得更加完全，但也更占资源（包括时间和空间资源）。举个例子，下面的场景，可以说明深拷贝和浅拷贝的区别。

if  __name__=="__main__":    dog_layer=simpleLayer()    dog_layer.paint("Dog")    dog_layer.fillBackground([0,0,255,0])    print "Original Background:",dog_layer.getBackgroud()    print "Original Painting:",dog_layer.getContent()    another_dog_layer=dog_layer.clone()    another_dog_layer.setParent(128)    another_dog_layer.paint("Puppy")    print "Original Background:", dog_layer.getBackgroud()    print "Original Painting:", dog_layer.getContent()    print "Copy Background:", another_dog_layer.getBackgroud()    print "Copy Painting:", another_dog_layer.getContent()

**打印如下：**Original Background: [0, 0, 255, 0]Original Painting: DogOriginal Background: [0, 0, 255, 128]Original Painting: DogCopy Background: [0, 0, 255, 128]Copy Painting: Puppy
浅拷贝后，直接对拷贝后引用（这里的数组）进行操作，原始对象中该引用的内容也会变动。如果将another_dog_layer=dog_layer.clone()换成another_dog_layer=dog_layer.deep_clone()，即把浅拷贝换成深拷贝，其如果如下：
Original Background: [0, 0, 255, 0]Original Painting: DogOriginal Background: [0, 0, 255, 0]Original Painting: DogCopy Background: [0, 0, 255, 128]Copy Painting: Puppy
深拷贝后，其对象内的引用内容也被进行了复制。

二、原型模式

原型模式定义如下：用原型实例指定创建对象的种类，并且通过复制这些原型创建新的对象。需要注意一点的是，进行clone操作后，新对象的构造函数没有被二次执行，新对象的内容是从内存里直接拷贝的。

三、原型模式的优点和使用场景

优点：

性能极佳，直接拷贝比在内存里直接新建实例节省不少的资源；2、简化对象创建，同时避免了构造函数的约束，不受构造函数的限制直接复制对象，是优点，也有隐患，这一点还是需要多留意一些。

使用场景：

对象在修改过后，需要复制多份的场景。如本例和其它一些涉及到复制、粘贴的场景；2、需要优化资源的情况。如，需要在内存中创建非常多的实例，可以通过原型模式来减少资源消耗。此时，原型模式与工厂模式配合起来，不管在逻辑上还是结构上，都会达到不错的效果；3、某些重复性的复杂工作不需要多次进行。如对于一个设备的访问权限，多个对象不用各申请一遍权限，由一个设备申请后，通过原型模式将权限交给可信赖的对象，既可以提升效率，又可以节约资源。

四、原型模式的缺点

深拷贝和浅拷贝的使用需要事先考虑周到；2、某些编程语言中，拷贝会影响到静态变量和静态函数的使用。

一、网络服务器配置白名单

代理模式是一种使用频率非常高的模式，在多个著名的开源软件和当前多个著名的互联网产品后台程序中都有所应用。下面我们用一个抽象化的简单例子，来说明代理模式。首先，构造一个网络服务器：

info_struct=dict()info_struct["addr"]=10000info_struct["content"]=""class Server:    content=""    def recv(self,info):        pass    def send(self,info):        pass    def show(self):        passclass infoServer(Server):    def recv(self,info):        self.content=info        return "recv OK!"    def send(self,info):        pass    def show(self):        print "SHOW:%s"%self.content

infoServer有接收和发送的功能，发送功能由于暂时用不到，保留。另外新加一个接口show，用来展示服务器接收的内容。接收的数据格式必须如info_struct所示，服务器仅接受info_struct的content字段。那么，如何给这个服务器设置一个白名单，使得只有白名单里的地址可以访问服务器呢？修改Server结构是个方法，但这显然不符合软件设计原则中的单一职责原则。在此基础之上，使用代理，是个不错的方法。代理配置如下：

class serverProxy:    passclass infoServerProxy(serverProxy):    server=""    def __init__(self,server):        self.server=server    def recv(self,info):        return self.server.recv(info)    def show(self):        self.server.show()class whiteInfoServerProxy(infoServerProxy):    white_list=[]    def recv(self,info):        try:            assert type(info)==dict        except:            return "info structure is not correct"        addr=info.get("addr",0)        if not addr in self.white_list:            return "Your address is not in the white list."        else:            content=info.get("content","")            return self.server.recv(content)    def addWhite(self,addr):        self.white_list.append(addr)    def rmvWhite(self,addr):        self.white_list.remove(addr)    def clearWhite(self):        self.white_list=[]

代理中有一个server字段，控制代理的服务器对象，infoServerProxy充当Server的直接接口代理，而whiteInfoServerProxy直接继承了infoServerProxy对象，同时加入了white_list和对白名单的操作。这样，在场景中通过对白名单代理的访问，就可以实现服务器的白名单访问了。

if  __name__=="__main__":    info_struct = dict()    info_struct["addr"] = 10010    info_struct["content"] = "Hello World!"    info_server = infoServer()    info_server_proxy = whiteInfoServerProxy(info_server)    print info_server_proxy.recv(info_struct)    info_server_proxy.show()    info_server_proxy.addWhite(10010)    print info_server_proxy.recv(info_struct)    info_server_proxy.show()

打印如下：
Your address is not in the white list.SHOW:recv OK!SHOW:Hello World!

二、代理模式

代理模式定义如下：为某对象提供一个代理，以控制对此对象的访问和控制。代理模式在使用过程中，应尽量对抽象主题类进行代理，而尽量不要对加过修饰和方法的子类代理。如上例中，如果有一个xServer继承了Server，并新加了方法xMethod，xServer的代理应以Server为主题进行设计，而尽量不要以xServer为主题，以xServer为主题的代理可以从ServerProxy继承并添加对应的方法。

在JAVA中，讲到代理模式，不得不会提到动态代理。动态代理是实现AOP（面向切面编程）的重要实现手段。而在Python中，很少会提到动态代理，而AOP则会以另一种模式实现：装饰模式。有关AOP的相关内容，我们会在装饰模式这一节中进行说明。

三、代理模式的优点和应用场景

优点:

职责清晰：非常符合单一职责原则，主题对象实现真实业务逻辑，而非本职责的事务，交由代理完成；2、扩展性强：面对主题对象可能会有的改变，代理模式在不改变对外接口的情况下，可以实现最大程度的扩展；3、保证主题对象的处理逻辑：代理可以通过检查参数的方式，保证主题对象的处理逻辑输入在理想范围内。

应用场景：

针对某特定对象进行功能和增强性扩展。如IP防火墙、远程访问代理等技术的应用；2、对主题对象进行保护。如大流量代理，安全代理等；3、减轻主题对象负载。如权限代理等。

四、代理模式的缺点

可能会降低整体业务的处理效率和速度。

一、快餐点餐系统

又提到了那个快餐点餐系统，不过今天我们只以其中的一个类作为主角：饮料类。首先，回忆下饮料类：

class Beverage():    name = ""    price = 0.0    type = "BEVERAGE"    def getPrice(self):        return self.price    def setPrice(self, price):        self.price = price    def getName(self):        return self.nameclass coke(Beverage):    def __init__(self):        self.name = "coke"        self.price = 4.0class milk(Beverage):    def __init__(self):        self.name = "milk"        self.price = 5.0

除了基本配置，快餐店卖可乐时，可以选择加冰，如果加冰的话，要在原价上加0.3元；卖牛奶时，可以选择加糖，如果加糖的话，要原价上加0.5元。怎么解决这样的问题？可以选择装饰器模式来解决这一类的问题。首先，定义装饰器类：

class drinkDecorator():    def getName(self):        pass    def getPrice(self):        passclass iceDecorator(drinkDecorator):    def __init__(self,beverage):        self.beverage=beverage    def getName(self):        return self.beverage.getName()+" +ice"    def getPrice(self):        return self.beverage.getPrice()+0.3class sugarDecorator(drinkDecorator):    def __init__(self,beverage):        self.beverage=beverage    def getName(self):        return self.beverage.getName()+" +sugar"    def getPrice(self):        return self.beverage.getPrice()+0.5

构建好装饰器后，在具体的业务场景中，就可以与饮料类进行关联。以可乐+冰为例，示例业务场景如下：

if  __name__=="__main__":    coke_cola=coke()    print "Name:%s"%coke_cola.getName()    print "Price:%s"%coke_cola.getPrice()    ice_coke=iceDecorator(coke_cola)    print "Name:%s" % ice_coke.getName()    print "Price:%s" % ice_coke.getPrice()

打印结果如下：
Name:cokePrice:4.0Name:coke +icePrice:4.3

二、装饰器模式

装饰器模式定义如下：动态地给一个对象添加一些额外的职责。在增加功能方面，装饰器模式比生成子类更为灵活。

装饰器模式和上一节说到的代理模式非常相似，可以认为，装饰器模式就是代理模式的一个特殊应用，两者的共同点是都具有相同的接口，不同点是侧重对主题类的过程的控制，而装饰模式则侧重对类功能的加强或减弱。上一次说到，JAVA中的动态代理模式，是实现AOP的重要手段。而在Python中，AOP通过装饰器模式实现更为简洁和方便。先来解释一下什么是AOP。AOP即Aspect
Oriented
Programming，中文翻译为面向切面的编程，它的含义可以解释为：如果几个或更多个逻辑过程中（这类逻辑过程可能位于不同的对象，不同的接口当中），有重复的操作行为，就可以将这些行为提取出来（即形成切面），进行统一管理和维护。举例子说，系统中需要在各个地方打印日志，就可以将打印日志这一操作提取出来，作为切面进行统一维护。从编程思想的关系来看，可以认为AOP和OOP（面向对象的编程）是并列关系，二者是可以替换的，也可以结合起来用。实际上，在Python语言中，是天然支持装饰器的，如下例：

def log(func):    def wrapper(*args, **kw):        print 'call %s():' % func.__name__        return func(*args, **kw)    return wrapper@logdef now():    print '2016-12-04'if  __name__=="__main__":    now()

打印如下：
call now():2016-12-04
log接口就是装饰器的定义，而Python的@语法部分则直接支持装饰器的使用。如果要在快餐点餐系统中打印日志，该如何进行AOP改造呢？可以借助类的静态方法或者类方法来实现：

class LogManager:    @staticmethod    def log(func):        def wrapper(*args):            print "Visit Func %s"%func.__name__            return func(*args)        return wrapper

在需要打印日志的地方直接@LogManager.log，即可打印出访问的日志信息。如，在beverage类的函数前加上@LogManager.log，场景类保持不变，则打印结果如下：

Visit Func getNameName:cokeVisit Func getPricePrice:4.0Visit Func getNameName:coke +iceVisit Func getPricePrice:4.3

三、装饰器模式的优点和应用场景

优点：

装饰器模式是继承方式的一个替代方案，可以轻量级的扩展被装饰对象的功能；2、Python的装饰器模式是实现AOP的一种方式，便于相同操作位于不同调用位置的统一管理。

应用场景：

需要扩展、增强或者减弱一个类的功能，如本例。

四、装饰器模式的缺点

多层装饰器的调试和维护有比较大的困难。

一、外包人员系统兼容

假设某公司A与某公司B需要合作，公司A需要访问公司B的人员信息，但公司A与公司B协议接口不同，该如何处理？先将公司A和公司B针对各自的人员信息访问系统封装了对象接口。

class ACpnStaff:    name=""    id=""    phone=""    def __init__(self,id):        self.id=id    def getName(self):        print "A protocol getName method...id:%s"%self.id        return self.name    def setName(self,name):        print "A protocol setName method...id:%s"%self.id        self.name=name    def getPhone(self):        print "A protocol getPhone method...id:%s"%self.id        return self.phone    def setPhone(self,phone):        print "A protocol setPhone method...id:%s"%self.id        self.phone=phoneclass BCpnStaff:    name=""    id=""    telephone=""    def __init__(self,id):        self.id=id    def get_name(self):        print "B protocol get_name method...id:%s"%self.id        return self.name    def set_name(self,name):        print "B protocol set_name method...id:%s"%self.id        self.name=name    def get_telephone(self):        print "B protocol get_telephone method...id:%s"%self.id        return self.telephone    def set_telephone(self,telephone):        print "B protocol get_name method...id:%s"%self.id        self.telephone=telephone

为在A公司平台复用B公司接口，直接调用B公司人员接口是个办法，但会对现在业务流程造成不确定的风险。为减少耦合，规避风险，我们需要一个帮手，就像是转换电器电压的适配器一样，这个帮手就是协议和接口转换的适配器。适配器构造如下：

class CpnStaffAdapter:    b_cpn=""    def __init__(self,id):        self.b_cpn=BCpnStaff(id)    def getName(self):        return self.b_cpn.get_name()    def getPhone(self):        return self.b_cpn.get_telephone()    def setName(self,name):        self.b_cpn.set_name(name)    def setPhone(self,phone):        self.b_cpn.set_telephone(phone)

适配器将B公司人员接口封装，而对外接口形式与A公司人员接口一致，达到用A公司人员接口访问B公司人员信息的效果。业务示例如下：

if __name__=="__main__":    acpn_staff=ACpnStaff("123")    acpn_staff.setName("X-A")    acpn_staff.setPhone("10012345678")    print "A Staff Name:%s"%acpn_staff.getName()    print "A Staff Phone:%s"%acpn_staff.getPhone()    bcpn_staff=CpnStaffAdapter("456")    bcpn_staff.setName("Y-B")    bcpn_staff.setPhone("99987654321")    print "B Staff Name:%s"%bcpn_staff.getName()    print "B Staff Phone:%s"%bcpn_staff.getPhone()

打印如下：

A protocol setName method…id:123A protocol setPhone method…id:123A protocol getName method…id:123A Staff Name:X-AA protocol getPhone method…id:123A Staff Phone:10012345678B protocol set_name method…id:456B protocol get_name method…id:456B protocol get_name method…id:456B Staff Name:Y-BB protocol get_telephone method…id:456B Staff Phone:99987654321

二、适配器模式

适配器模式定义如下：将一个类的接口变换成客户端期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。适配器模式和装饰模式有一定的相似性，都起包装的作用，但二者本质上又是不同的，装饰模式的结果，是给一个对象增加了一些额外的职责，而适配器模式，则是将另一个对象进行了“伪装”。

适配器可以认为是对现在业务的补偿式应用，所以，尽量不要在设计阶段使用适配器模式，在两个系统需要兼容时可以考虑使用适配器模式。

三、适配器模式的优点和使用场景

优点：

适配器模式可以让两个接口不同，甚至关系不大的两个类一起运行；2、提高了类的复用度，经过“伪装”的类，可以充当新的角色；3、适配器可以灵活“拆卸”。

应用场景：

不修改现有接口，同时也要使该接口适用或兼容新场景业务中，适合使用适配器模式。例如，在一个嵌入式系统中，原本要将数据从Flash读入，现在需要将数据从磁盘读入，这种情况可以使用适配器模式，将从磁盘读入数据的接口进行“伪装”，以从Flash中读数据的接口形式，从磁盘读入数据。

四、适配器模式的缺点

适配器模式与原配接口相比，毕竟增加了一层调用关系，所以，在设计系统时，不要使用适配器模式。

一、火警报警器（1）

假设有一组火警报警系统，由三个子元件构成：一个警报器，一个喷水器，一个自动拨打电话的装置。其抽象如下：

class AlarmSensor:    def run(self):        print "Alarm Ring..."class WaterSprinker:    def run(self):        print "Spray Water..."class EmergencyDialer:    def run(self):        print "Dial 119..."

在业务中如果需要将三个部件启动，例如，如果有一个烟雾传感器，检测到了烟雾。在业务环境中需要做如下操作：

if __name__=="__main__":    alarm_sensor=AlarmSensor()    water_sprinker=WaterSprinker()    emergency_dialer=EmergencyDialer()    alarm_sensor.run()    water_sprinker.run()    emergency_dialer.run()

但如果在多个业务场景中需要启动三个部件，怎么办？Ctrl+C加上Ctrl+V么？当然可以这样，但作为码农的基本修养之一，减少重复代码是应该会被很轻易想到的方法。这样，需要将其进行封装，在设计模式中，被封装成的新对象，叫做门面。门面构建如下：

class EmergencyFacade:    def __init__(self):        self.alarm_sensor=AlarmSensor()        self.water_sprinker=WaterSprinker()        self.emergency_dialer=EmergencyDialer()    def runAll(self):        self.alarm_sensor.run()        self.water_sprinker.run()        self.emergency_dialer.run()

这样，业务场景中这样写就可以了：

if __name__=="__main__":    emergency_facade=EmergencyFacade()    emergency_facade.runAll()

打印如下：

Alarm Ring…Spray Water…Dial 119…

二、门面模式

门面模式也叫外观模式，定义如下：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。门面模式注重“统一的对象”，也就是提供一个访问子系统的接口。门面模式与之前说过的模板模式有类似的地方，都是对一些需要重复方法的封装。但从本质上来说，是不同的。模板模式是对类本身的方法的封装，其被封装的方法也可以单独使用；而门面模式，是对子系统的封装，其被封装的接口理论上是不会被单独提出来用的。

三、门面模式的优点和使用场景

优点：

减少了系统之间的相互依赖，提高了系统的灵活；2、提高了整体系统的安全性：封装起的系统对外的接口才可以用，隐藏了很多内部接口细节，若方法不允许使用，则在门面中可以进行灵活控制。

使用场景：

为一个复杂的子系统提供一个外界访问的接口。这类例子是生活还是蛮常见的，例如电视遥控器的抽象模型，电信运营商的用户交互设备等；2、需要简化操作界面时。例如常见的扁平化系统操作界面等，在生活中和工业中都很常见。

四、门面模式的缺点

门面模式的缺点在于，不符合开闭原则，一旦系统成形后需要修改，几乎只能重写门面代码，这比继承或者覆写等方式，或者其它一些符合开闭原则的模式风险都会大一些。

一、公司结构组织

每一个公司都有自己的组织结构，越是大型的企业，其组织结构就会越复杂。大多数情况下，公司喜欢用“树形”结构来组织复杂的公司人事关系和公司间的结构关系。一般情况下，根结点代表公司的最高行政权利单位，分支节点表示一个个部门，而叶子结点则会用来代表每一个员工。每一个结点的子树，表示该结点代表的部门所管理的单位。假设一个具有HR部门，财务部门和研发部门，同时在全国有分支公司的总公司，其公司结构，可以表示成如下逻辑：

class Company:    name = ''    def __init__(self, name):        self.name = name    def add(self, company):        pass    def remove(self, company):        pass    def display(self, depth):        pass    def listDuty(self):        passclass ConcreteCompany(Company):    childrenCompany = None    def __init__(self, name):        Company.__init__(self,name)        self.childrenCompany = []    def add(self, company):        self.childrenCompany.append(company)    def remove(self, company):        self.childrenCompany.remove(company)    def display(self, depth):        print'-'*depth + self.name        for component in self.childrenCompany:            component.display(depth+1)    def listDuty(self):        for component in self.childrenCompany:            component.listDuty()class HRDepartment(Company):    def __init__(self, name):         Company.__init__(self,name)    def display(self, depth):        print '-'*depth + self.name    def listDuty(self):         print '%s\t Enrolling & Transfering management.' % self.nameclass FinanceDepartment(Company):    def __init__(self, name):        Company.__init__(self,name)    def display(self, depth):        print "-" * depth + self.name    def listDuty(self):         print '%s\tFinance Management.'%self.nameclass RdDepartment(Company):    def __init__(self,name):        Company.__init__(self,name)    def display(self, depth):        print "-"*depth+self.name    def listDuty(self):        print "%s\tResearch & Development."% self.name

在该例中，公司结构抽象仅考虑公司（ConcreteCompany）和部门（Department），公司有子公司的可能性，公司也有自己的部门，部门是最终的叶子结点。 假设总公司下设东边的分公司一个，东边的分公司下设东北公司和东南公司，显示公司层级，并罗列这些的公司中各部门的职责，可以构建如下业务场景：

if __name__=="__main__":    root = ConcreteCompany('HeadQuarter')    root.add(HRDepartment('HQ HR'))    root.add(FinanceDepartment('HQ Finance'))    root.add(RdDepartment("HQ R&D"))    comp = ConcreteCompany('East Branch')    comp.add(HRDepartment('East.Br HR'))    comp.add(FinanceDepartment('East.Br Finance'))    comp.add(RdDepartment("East.Br R&D"))    root.add(comp)    comp1 = ConcreteCompany('Northast Branch')    comp1.add(HRDepartment('Northeast.Br HR'))    comp1.add(FinanceDepartment('Northeast.Br Finance'))    comp1.add(RdDepartment("Northeast.Br R&D"))    comp.add(comp1)    comp2 = ConcreteCompany('Southeast Branch')    comp2.add(HRDepartment('Southeast.Br HR'))    comp2.add(FinanceDepartment('Southeast.Br Finance'))    comp2.add(RdDepartment("Southeast.Br R&D"))    comp.add(comp2)    root.display(1)    root.listDuty()

打印如下：

-HeadQuarter–HQ HR–HQ Finance–HQ R&D–East Branch—East.Br HR—East.Br Finance—East.Br R&D—Northast Branch----Northeast.Br HR----Northeast.Br Finance----Northeast.Br R&D—Southeast Branch----Southeast.Br HR----Southeast.Br Finance----Southeast.Br R&DHQ HR Enrolling & Transfering management.HQ Finance Finance Management.HQ R&D Research & Development.East.Br HR Enrolling & Transfering management.East.Br Finance Finance Management.East.Br R&D Research & Development.Northeast.Br HR Enrolling & Transfering management.Northeast.Br Finance Finance Management.Northeast.Br R&D Research & Development.Southeast.Br HR Enrolling & Transfering management.Southeast.Br Finance Finance Management.Southeast.Br R&D Research & Development.

二、组合模式

组合模式也叫作部分-整体模式，其定义如下：将对象组合成树形结构以表示“部分”和“整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。

三、组合模式的优点和使用场景

优点：

节点增加和减少是非常自由和方便的，这也是树形结构的一大特点；2、所有节点，不管是分支节点还是叶子结点，不管是调用一个结点，还是调用一个结点群，都是非常方便的。

使用场景：

维护部分与整体的逻辑关系，或者动态调用整体或部分的功能接口，可以考虑使用组合模式。例如，非常多的操作系统（如Linux）都把文件系统设计成树形结构，再比如说分布式应用中借助Zookeeper，也可以组织和调用分布式集群中的结点功能。

四、组合模式的缺点

由于叶子结点和分支结点直接使用了实现类，而不方便使用抽象类，这大大限制了接口的影响范围；若结点接口发生变更，对系统造成的风险会比较大。

一、网上咖啡选购平台

假设有一个网上咖啡选购平台，客户可以在该平台上下订单订购咖啡，平台会根据用户位置进行线下配送。假设其咖啡对象构造如下：

class Coffee:    name = ''    price =0    def __init__(self,name):        self.name = name        self.price = len(name)    def show(self):        print "Coffee Name:%s Price:%s"%(self.name,self.price)

其对应的顾客类如下：

class Customer:    name=""    def __init__(self,name):        self.name=name    def order(self,coffee_name):        print "%s ordered a cup of coffee:%s"%(self.name,coffee_name)        return Coffee(coffee_name)

按照一般的处理流程，用户在网上预订咖啡，其代表用户的Customer类中生成一个Coffee类，直到交易流程结束。整个流程是没有问题的。如果，随着网站用户越来越多，单位时间内购买咖啡的用户也越来越多，并发量越来越大，对系统资源的消耗也会越来越大，极端情况下，会造成宕机等严重后果。此时，高效利用资源，就显得非常重要了。简单分析下业务流程，高并发下用户数量增加，而该模型下，每个用户点一杯咖啡，就会产生一个咖啡实例，如果一种咖啡在该时间内被很多用户点过，那么就会产生很多同样咖啡的实例。避免重复实例的出现，是节约系统资源的一个突破口。类似于单例模式，我们这里在咖啡实例化前，增加一个控制实例化的类：咖啡工厂。

class CoffeeFactory():    coffee_dict = {}    def getCoffee(self, name):        if self.coffee_dict.has_key(name) == False:            self.coffee_dict[name] = Coffee(name)        return self.coffee_dict[name]    def getCoffeeCount(self):        return len(self.coffee_dict)

咖啡工厂中，getCoffeeCount直接返回当前实例个数。Customer类可以重写下，如下：

class Customer:    coffee_factory=""    name=""    def __init__(self,name,coffee_factory):        self.name=name        self.coffee_factory=coffee_factory    def order(self,coffee_name):        print "%s ordered a cup of coffee:%s"%(self.name,coffee_name)        return self.coffee_factory.getCoffee(coffee_name)

假设业务中短时间内有多人订了咖啡，业务模拟如下：

if __name__=="__main__":    coffee_factory=CoffeeFactory()    customer_1=Customer("A Client",coffee_factory)    customer_2=Customer("B Client",coffee_factory)    customer_3=Customer("C Client",coffee_factory)    c1_capp=customer_1.order("cappuccino")    c1_capp.show()    c2_mocha=customer_2.order("mocha")    c2_mocha.show()    c3_capp=customer_3.order("cappuccino")    c3_capp.show()    print "Num of Coffee Instance:%s"%coffee_factory.getCoffeeCount()

打印如下：

A Client ordered a cup of coffee:cappuccinoCoffee Name:cappuccino Price:10B Client ordered a cup of coffee:mochaCoffee Name:mocha Price:5C Client ordered a cup of coffee:cappuccinoCoffee Name:cappuccino Price:10Num of Coffee Instance:2

根据结果可以得知，该模式下三个用户点了两种咖啡，最终的咖啡实例为2，而不是3。

二、享元模式

享元模式定义如下：使用共享对象支持大量细粒度对象。大量细粒度的对象的支持共享，可能会涉及这些对象的两类信息：内部状态信息和外部状态信息。内部状态信息就是可共享出来的信息，它们存储在享元对象内部，不会随着特定环境的改变而改变；外部状态信息就不可共享的信息了。享元模式中只包含内部状态信息，而不应该包含外部状态信息。这点在设计业务架构时，应该有所考虑。

三、享元模式的优点和使用场景

优点：

减少重复对象，大大节约了系统资源。

使用场景：

系统中存在大量的相似对象时，可以选择享元模式提高资源利用率。咖啡订购平台比较小，若假设一个电商平台，每个买家和卖家建立起买卖关系后，买家对象和卖家对象都是占用资源的。如果一个卖家同时与多个买家建立起买卖关系呢？此时享元模式的优势就体现出来了；2、需要缓冲池的场景中，可以使用享元模式。如进程池，线程池等技术，就可以使用享元模式（事实上，很多的池技术中已经使得了享元模式）。

四、享元模式的缺点

享元模式虽然节约了系统资源，但同时也提高了系统的复杂性，尤其当遇到外部状态和内部状态混在一起时，需要先将其进行分离，才可以使用享元模式。否则，会引起逻辑混乱或业务风险；2、享元模式中需要额外注意线程安全问题。

一、画笔与形状

在介绍原型模式的一节中，我们举了个图层的例子，这一小节内容，我们同样以类似画图的例子，说明一种结构类设计模式：桥梁模式。在一个画图程序中，常会见到这样的情况：有一些预设的图形，如矩形、圆形等，还有一个对象-画笔，调节画笔的类型（如画笔还是画刷，还是毛笔效果等）并设定参数（如颜色、线宽等），选定图形，就可以在画布上画出想要的图形了。要实现以上需求，先从最抽象的元素开始设计，即形状和画笔（暂时忽略画布，同时忽略画笔参数，只考虑画笔类型）。

class Shape:    name=""    param=""    def __init__(self,*param):        pass    def getName(self):        return self.name    def getParam(self):        return self.name,self.paramclass Pen:    shape=""    type=""    def __init__(self,shape):        self.shape=shape    def draw(self):        pass

形状对象和画笔对象是最为抽象的形式。接下来，构造多个形状，如矩形和圆形：

class Rectangle(Shape):    def __init__(self,long,width):        self.name="Rectangle"        self.param="Long:%s Width:%s"%(long,width)        print "Create a rectangle:%s"%self.paramclass Circle(Shape):    def __init__(self,radius):        self.name="Circle"        self.param="Radius:%s"%radius        print "Create a circle:%s"%self.param

紧接着是构造多种画笔，如普通画笔和画刷：

class NormalPen(Pen):    def __init__(self,shape):        Pen.__init__(self,shape)        self.type="Normal Line"    def draw(self):        print "DRAWING %s:%s----PARAMS:%s"%(self.type,self.shape.getName(),self.shape.getParam())class BrushPen(Pen):    def __init__(self,shape):        Pen.__init__(self,shape)        self.type="Brush Line"    def draw(self):        print "DRAWING %s:%s----PARAMS:%s" % (self.type,self.shape.getName(), self.shape.getParam())

业务中的逻辑如下：

if __name__=="__main__":    normal_pen=NormalPen(Rectangle("20cm","10cm"))    brush_pen=BrushPen(Circle("15cm"))    normal_pen.draw()    brush_pen.draw()

打印如下：

Create a rectangle:Long:20cm Width:10cmCreate a circle:Radius:15cmDRAWING Normal Line:Rectangle----PARAMS:(‘Rectangle’, ‘Long:20cm Width10cm’)DRAWING Brush Line:Circle----PARAMS:(‘Circle’, ‘Radius:15cm’)

二、桥梁模式

桥梁模式又叫桥接模式，定义如下：将抽象与实现解耦（注意此处的抽象和实现，并非抽象类和实现类的那种关系，而是一种角色的关系，这里需要好好区分一下），可以使其独立变化。在形如上例中，Pen只负责画，但没有形状，它终究是不知道要画什么的，所以我们把它叫做抽象化角色；而Shape是具体的形状，我们把它叫做实现化角色。抽象化角色和实现化角色是解耦的，这也就意味着，所谓的桥，就是抽象化角色的抽象类和实现化角色的抽象类之间的引用关系。

三、桥梁模式的优点和应用场景

优点：

抽象角色与实现角色相分离，二者可以独立设计，不受约束；2、扩展性强：抽象角色和实现角色可以非常灵活地扩展。

应用场景：

不适用继承或者原继承关系中抽象类可能频繁变动的情况，可以将原类进行拆分，拆成实现化角色和抽象化角色。例如本例中，若将形状、粗细、绘画样式等属于汇集在一个类中，一旦抽象类中有所变动，将造成巨大的风险；2、重用性比较大的场景。比如开关控制逻辑的程序，开关就是抽象化角色，开关的形式有很多种，操作的实现化角色也有很多种，采用桥梁模式，（如当前例子）开关即可进行复用，整体会将设计的粒度减小。

四、桥梁模式的缺点

增加对系统理解的难度。

一、客户消息通知

假设某司维护着一些客户资料，需要在该司有新产品上市或者举行新活动时通知客户。现通知客户的方式有两种：短信通知、邮件通知。应如何设计该系统的客户通知部分？为解决该问题，我们先构造客户类，包括客户常用的联系方式和基本信息，同时也包括要发送的内容。

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):        passclass 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[1] EMAIL:Welcome to our new party!

二、策略模式

策略模式定义如下：定义一组算法，将每个算法都封装起来，并使他们之间可互换。以上述例子为例，customer类扮演的角色（Context）直接依赖抽象策略的接口，在具体策略实现类中即可定义个性化的策略方式，且可以方便替换。

上一节中我们介绍了桥接模式，仔细比较一下桥接模式和策略模式，如果把策略模式的Context设计成抽象类和实现类的方式，那么策略模式和桥接模式就可以划等号了。从类图看上去，桥接模式比策略模式多了对一种角色（抽象角色）的抽象。二者结构的高度同构，也只能让我们从使用意图上去区分两种模式：桥接模式解决抽象角色和实现角色都可以扩展的问题；而策略模式解决算法切换和扩展的问题。

三、策略模式的优点和应用场景

优点：

各个策略可以自由切换：这也是依赖抽象类设计接口的好处之一；2、减少代码冗余；3、扩展性优秀，移植方便，使用灵活。

应用场景：

算法策略比较经常地需要被替换时，可以使用策略模式。如现在超市前台，会常遇到刷卡、某宝支付、某信支付等方式，就可以参考策略模式。

四、策略模式的缺点

项目比较庞大时，策略可能比较多，不便于维护；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):        passclass 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 OVERLINE MANAGER:Ask 5 days off Num:5 Accepted CONTINUEDEPARTMENT MANAGER:Ask 5 days off Num:5 Accepted OVERLINE MANAGER:Ask 10 days off Num:10 Accepted CONTINUEDEPARTMENT MANAGER:Ask 10 days off Num:10 Accepted CONTINUEGENERAL MANAGER:Ask 10 days off Num:10 Accepted OVER

二、责任链模式

责任链模式的定义如下：使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

需要说明的是，责任链模式中的应该只有一个处理者，也就是说，本例中的“最终批准”为该对象所谓的“请求处理”。

三、责任链模式的优点和应用场景

优点：

将请求者与处理者分离，请求者并不知道请求是被哪个处理者所处理，易于扩展。

应用场景：

若一个请求可能由一个对请求有链式优先级的处理群所处理时，可以考虑责任链模式。除本例外，银行的客户请求处理系统也可以用责任链模式实现（VIP客户和普通用户处理方式当然会有不同）。

四、责任链模式的缺点

如果责任链比较长，会有比较大的性能问题；2、如果责任链比较长，若业务出现问题，比较难定位是哪个处理者的问题。

一、饭店点餐系统

又是一个点餐系统（原谅作者的吃货属性）。不过这次的点餐系统是个饭店的点餐系统。饭店的点餐系统有什么不同嘛？大伙想想看，在大多数饭店中，当服务员已经接到顾客的点单，录入到系统中后，根据不同的菜品，会有不同的后台反应。比如，饭店有凉菜间、热菜间、主食间，那当服务员将菜品录入到系统中后，凉菜间会打印出顾客所点的凉菜条目，热菜间会打印出顾客所点的热菜条目，主食间会打印出主食条目。那这个系统的后台模式该如何设计？当然，直接在场景代码中加if…else…语句判断是个方法，可这样做又一次加重了系统耦合，违反了单一职责原则，遇到系统需求变动时，又会轻易违反开闭原则。所以，我们需要重新组织一下结构。可以将该系统设计成前台服务员系统和后台系统，后台系统进一步细分成主食子系统，凉菜子系统，热菜子系统。后台三个子系统设计如下：

class backSys():    def cook(self,dish):        passclass mainFoodSys(backSys):    def cook(self,dish):        print "MAINFOOD:Cook %s"%dishclass coolDishSys(backSys):    def cook(self,dish):        print "COOLDISH:Cook %s"%dishclass 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):        passclass 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):    passclass coolDishCommand(foodCommand):    passclass 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 dishWAITER:Add dishWAITER:Add dishWAITER:Add dishWAITER:Nofify…HOTDISH:Cook Yu-Shiang Shredded PorkHOTDISH:Cook Sauteed Tofu, Home StyleCOOLDISH:Cook CucumberMAINFOOD:Cook Rice

二、命令模式

命令模式的定义为：将一个请求封装成一个对象，从而可以使用不同的请求将客户端参数化，对请求排队或者记录请求日志，可以提供命令的撤销和恢复功能。命令模式中通常涉及三类对象的抽象：Receiver，Command，Invoker（本例中的waiterSys）。

只有一个Invoker的命令模式也可以抽象成一个类似的“星形网络”，但与之前介绍的中介者模式不同，单纯的命令模式更像是一个辐射状的结构，由Invoker直接对Receiver传递命令，而一般不反向传递，中介者模式“星形网络”的中心，是个协调者，抽象结节间的信息流全部或者部分是双向的。另外，命令模式的定义中提到了“撤销和恢复功能”，也给了各位开发人员一个命令模式使用过程中的建议：各个Receiver中可以设计一个回滚接口，支持命令的“撤销”。

三、命令模式的优点和应用场景

优点：

低耦合：调用者和接收者之间没有什么直接关系，二者通过命令中的execute接口联系；2、扩展性好：新命令很容易加入，也很容易拼出“组合命令”。

应用场景：

触发-反馈机制的系统，都可以使用命令模式思想。如基于管道结构的命令系统（如SHELL），可以直接套用命令模式；此外，GUI系统中的操作反馈（如点击、键入等），也可以使用命令模式思想。

四、命令模式的缺点

如果业务场景中命令比较多，那么对应命令类和命令对象的数量也会增加，这样系统会膨胀得很大。

一、仓储管理系统

有一个手机仓储管理系统，使用者有三方：销售、仓库管理员、采购。需求是：销售一旦达成订单，销售人员会通过系统的销售子系统部分通知仓储子系统，仓储子系统会将可出仓手机数量减少，同时通知采购管理子系统当前销售订单；仓储子系统的库存到达阈值以下，会通知销售子系统和采购子系统，并督促采购子系统采购；采购完成后，采购人员会把采购信息填入采购子系统，采购子系统会通知销售子系统采购完成，并通知仓库子系统增加库存。从需求描述来看，每个子系统都和其它子系统有所交流，在设计系统时，如果直接在一个子系统中集成对另两个子系统的操作，一是耦合太大，二是不易扩展。为解决这类问题，我们需要引入一个新的角色-中介者-来将“网状结构”精简为“星形结构”。（为充分说明设计模式，某些系统细节暂时不考虑，例如：仓库满了怎么办该怎么设计。类似业务性的内容暂时不考虑）首先构造三个子系统，即三个类（在中介者模式中，这些类叫做同事些）：

class colleague():    mediator = None    def __init__(self,mediator):        self.mediator = mediatorclass 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"%contentclass warehouseColleague(colleague):    total=0    threshold=100    def setThreshold(self,threshold):        self.threshold=threshold    def isEnough(self):        if self.totalself.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):        passclass 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 300MEDIATOR:Get Info–buyWAREHOUSE:Increase 300MEDIATOR:Get Info–increaseSALES:Get Notice–Inc 300PURCHASE:Get Notice–Inc 300SALES:Get Notice–Bought 300SALES:Sell 120MEDIATOR:Get Info–sellWAREHOUSE:Decrease 120MEDIATOR:Get Info–decreaseSALES:Get Notice–Dec 120PURCHASE:Get Notice–Dec 120WAREHOUSE:Warning…Stock is low… MEDIATOR:Get Info–warningSALES:Get Notice–Stock is low.180 Left.PURCHASE:Get Notice–Stock is low. Please Buy More!!! 180 LeftPURCHASE:Get Notice–Sold 120

二、中介者模式

中介者模式的定义为：用一个中介对象封装一系列的对象交互。中介者使各对象不需要显式地互相作用，从而使其耦合松散，并可以独立地改变它们之间的交互。

三、中介者模式的优点和应用场景

优点：

减少类与类的依赖，降低了类和类之间的耦合；2、容易扩展规模。

应用场景：

设计类图时，出现了网状结构时，可以考虑将类图设计成星型结构，这样就可以使用中介者模式了。如机场调度系统（多个跑道、飞机、指挥塔之间的调度）、路由系统；著名的MVC框架中，其中的C（Controller）就是M（Model）和V（View）的中介者。

四、中介者模式的缺点

中介者本身的复杂性可能会很大，例如，同事类的方法如果很多的话，本例中的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:myPwdAWeb 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

二、模板模式

模板模式定义如下：定义一个操作中的算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义该算法的某些特定的步骤。子类实现的具体方法叫作基本方法，实现对基本方法高度的框架方法，叫作模板方法。

三、模板模式的优点和应用

优点：

可变的部分可以充分扩展，不变的步骤可以充分封装；2、提取公共代码，减少冗余代码，便于维护；3、具体过程可以定制，总体流程方便掌控。

使用场景：

某超类的子类中有公有的方法，并且逻辑基本相同，可以使用模板模式。必要时可以使用钩子方法约束其行为。具体如本节例子；2、比较复杂的算法，可以把核心算法提取出来，周边功能在子类中实现。例如，机器学习中的监督学习算法有很多，如决策树、KNN、SVM等，但机器学习的流程大致相同，都包含输入样本、拟合（fit）、预测等过程，这样就可以把这些过程提取出来，构造模板方法，并通过钩子方法控制流程。

四、模板模式的缺点

模板模式在抽象类中定义了子类的方法，即子类对父类产生了影响，部分影响了代码的可读性。

一、迭代器与生成器

今天的主角是迭代器模式。在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 Alicehello Bobhello EveTraceback (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

打印如下：

0149162536496481

**注意*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

if __name__=="__main__":    x_square=MyGenerater(10)    for x in x_square:        print x

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):        passclass 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):        passclass 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())

class ObjectStructure:    passclass 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)

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.0CHARGE: Doctor Strange lists the Medicine Penicillin. Price:3.0PHARMACY:Doctor Wei offers the Medicine Yinqiao Pill. Price:2.0PHARMACY:Doctor Wei offers the Medicine Penicillin. Price:3.0

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)

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):        passclass 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..."

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

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…

class PlayContext():    play_text = Noneclass 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):        passclass NormGuitar(Expression):    def execute(self, key, value):        print "Normal Guitar Playing--Chord:%s Play Tune:%s"%(key,value)

if __name__=="__main__":    context = PlayContext()    context.play_text = "C53231323 Em43231323 F43231323 G63231323"    guitar=NormGuitar()    guitar.interpret(context)

Normal Guitar Playing–Chord:C Play Tune:53231323Normal Guitar Playing–Chord:Em Play Tune:43231323Normal Guitar Playing–Chord:F Play Tune:43231323Normal Guitar Playing–Chord:G Play Tune:63231323

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.defenseclass FightCharactor(GameCharacter):    def fight(self):        self.vitality -= random.randint(1,10)

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:100Attack:79Defence:60Current Values:Life:91Attack:79Defence:60Current Values:Life:100Attack:79Defence:60

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 selfclass 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())

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 closedSTOP:The lift start to run…RUN:The lift start to stop…RUN:The lift stopped…