代理模式
一、网络服务器配置白名单
代理模式是一种使用频率非常高的模式，在多个著名的开源软件和当前多个著名的互联网产品后台程序中都有所应用。下面我们用一个抽象化的简单例子，来说明代理模式。
首先，构造一个网络服务器：
#该服务器接受如下格式数据，addr代表地址，content代表接收的信息内容
info_struct=dict()
info_struct["addr"]=10000
info_struct["content"]=""
class Server:
content=""
def recv(self,info):
pass
def send(self,info):
pass
def show(self):
pass
class 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:
pass
class 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的相关内容，我们会在装饰模式这一节中进行说明。
三、代理模式的优点和应用场景
优点:
1、职责清晰：非常符合单一职责原则，主题对象实现真实业务逻辑，而非本职责的事务，交由代理完成；
2、扩展性强：面对主题对象可能会有的改变，代理模式在不改变对外接口的情况下，可以实现最大程度的扩展；
3、保证主题对象的处理逻辑：代理可以通过检查参数的方式，保证主题对象的处理逻辑输入在理想范围内。
应用场景：
1、针对某特定对象进行功能和增强性扩展。如IP防火墙、远程访问代理等技术的应用；
2、对主题对象进行保护。如大流量代理，安全代理等；
3、减轻主题对象负载。如权限代理等。
四、代理模式的缺点
1、可能会降低整体业务的处理效率和速度。
装饰器模式
一、快餐点餐系统
又提到了那个快餐点餐系统，不过今天我们只以其中的一个类作为主角：饮料类。首先，回忆下饮料类：
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.name
class coke(Beverage):
def __init__(self):
self.name = "coke"
self.price = 4.0
class 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):
pass
class 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.3
class 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:coke
Price:4.0
Name:coke +ice
Price: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
@log
def 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 getName
Name:coke
Visit Func getPrice
Price:4.0
Visit Func getName
Name:coke +ice
Visit Func getPrice
Price:4.3
三、装饰器模式的优点和应用场景
优点：
1、装饰器模式是继承方式的一个替代方案，可以轻量级的扩展被装饰对象的功能；
2、Python的装饰器模式是实现AOP的一种方式，便于相同操作位于不同调用位置的统一管理。
应用场景：
1、需要扩展、增强或者减弱一个类的功能，如本例。
四、装饰器模式的缺点
1、多层装饰器的调试和维护有比较大的困难。
适配器模式
一、外包人员系统兼容
假设某公司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=phone
class 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:123
A protocol setPhone method...id:123
A protocol getName method...id:123
A Staff Name:X-A
A protocol getPhone method...id:123
A Staff Phone:10012345678
B protocol set_name method...id:456
B protocol get_name method...id:456
B protocol get_name method...id:456
B Staff Name:Y-B
B protocol get_telephone method...id:456
B Staff Phone:99987654321
二、适配器模式
适配器模式定义如下：将一个类的接口变换成客户端期待的另一种接口，从而使原本因接口不匹配而无法在一起工作的两个类能够在一起工作。适配器模式和装饰模式有一定的相似性，都起包装的作用，但二者本质上又是不同的，装饰模式的结果，是给一个对象增加了一些额外的职责，而适配器模式，则是将另一个对象进行了“伪装”。
适配器可以认为是对现在业务的补偿式应用，所以，尽量不要在设计阶段使用适配器模式，在两个系统需要兼容时可以考虑使用适配器模式。
三、适配器模式的优点和使用场景
优点：
1、适配器模式可以让两个接口不同，甚至关系不大的两个类一起运行；
2、提高了类的复用度，经过“伪装”的类，可以充当新的角色；
3、适配器可以灵活“拆卸”。
应用场景：
1、不修改现有接口，同时也要使该接口适用或兼容新场景业务中，适合使用适配器模式。例如，在一个嵌入式系统中，原本要将数据从Flash读入，现在需要将数据从磁盘读入，这种情况可以使用适配器模式，将从磁盘读入数据的接口进行“伪装”，以从Flash中读数据的接口形式，从磁盘读入数据。
四、适配器模式的缺点
1、适配器模式与原配接口相比，毕竟增加了一层调用关系，所以，在设计系统时，不要使用适配器模式。
门面模式
一、火警报警器（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...
二、门面模式
门面模式也叫外观模式，定义如下：要求一个子系统的外部与其内部的通信必须通过一个统一的对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。门面模式注重“统一的对象”，也就是提供一个访问子系统的接口。门面模式与之前说过的模板模式有类似的地方，都是对一些需要重复方法的封装。但从本质上来说，是不同的。模板模式是对类本身的方法的封装，其被封装的方法也可以单独使用；而门面模式，是对子系统的封装，其被封装的接口理论上是不会被单独提出来用的。
三、门面模式的优点和使用场景
优点：
1、减少了系统之间的相互依赖，提高了系统的灵活；
2、提高了整体系统的安全性：封装起的系统对外的接口才可以用，隐藏了很多内部接口细节，若方法不允许使用，则在门面中可以进行灵活控制。
使用场景：
1、为一个复杂的子系统提供一个外界访问的接口。这类例子是生活还是蛮常见的，例如电视遥控器的抽象模型，电信运营商的用户交互设备等；
2、需要简化操作界面时。例如常见的扁平化系统操作界面等，在生活中和工业中都很常见。
四、门面模式的缺点
1、门面模式的缺点在于，不符合开闭原则，一旦系统成形后需要修改，几乎只能重写门面代码，这比继承或者覆写等方式，或者其它一些符合开闭原则的模式风险都会大一些。
组合模式
一、公司结构组织
每一个公司都有自己的组织结构，越是大型的企业，其组织结构就会越复杂。大多数情况下，公司喜欢用“树形”结构来组织复杂的公司人事关系和公司间的结构关系。一般情况下，根结点代表公司的最高行政权利单位，分支节点表示一个个部门，而叶子结点则会用来代表每一个员工。每一个结点的子树，表示该结点代表的部门所管理的单位。假设一个具有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):
pass
class 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 Enrolling & Transfering management.' % self.name
class FinanceDepartment(Company):
def __init__(self, name):
Company.__init__(self,name)
def display(self, depth):
print "-" * depth + self.name
def listDuty(self): #履行职责
print '%s Finance Management.'%self.name
class RdDepartment(Company):
def __init__(self,name):
Company.__init__(self,name)
def display(self, depth):
print "-"*depth+self.name
def listDuty(self):
print "%s Research & 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&D
HQ 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.
二、组合模式
组合模式也叫作部分-整体模式，其定义如下：将对象组合成树形结构以表示“部分”和“整体”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。
三、组合模式的优点和使用场景
优点：
1、节点增加和减少是非常自由和方便的，这也是树形结构的一大特点；
2、所有节点，不管是分支节点还是叶子结点，不管是调用一个结点，还是调用一个结点群，都是非常方便的。
使用场景：
1、维护部分与整体的逻辑关系，或者动态调用整体或部分的功能接口，可以考虑使用组合模式。例如，非常多的操作系统（如Linux）都把文件系统设计成树形结构，再比如说分布式应用中借助Zookeeper，也可以组织和调用分布式集群中的结点功能。
四、组合模式的缺点
1、由于叶子结点和分支结点直接使用了实现类，而不方便使用抽象类，这大大限制了接口的影响范围；若结点接口发生变更，对系统造成的风险会比较大。
享元模式
一、网上咖啡选购平台
假设有一个网上咖啡选购平台，客户可以在该平台上下订单订购咖啡，平台会根据用户位置进行线下配送。假设其咖啡对象构造如下：
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:cappuccino
Coffee Name:cappuccino Price:10
B Client ordered a cup of coffee:mocha
Coffee Name:mocha Price:5
C Client ordered a cup of coffee:cappuccino
Coffee Name:cappuccino Price:10
Num of Coffee Instance:2
根据结果可以得知，该模式下三个用户点了两种咖啡，最终的咖啡实例为2，而不是3。
二、享元模式
享元模式定义如下：使用共享对象支持大量细粒度对象。大量细粒度的对象的支持共享，可能会涉及这些对象的两类信息：内部状态信息和外部状态信息。内部状态信息就是可共享出来的信息，它们存储在享元对象内部，不会随着特定环境的改变而改变；外部状态信息就不可共享的信息了。享元模式中只包含内部状态信息，而不应该包含外部状态信息。这点在设计业务架构时，应该有所考虑。
三、享元模式的优点和使用场景
优点：
1、减少重复对象，大大节约了系统资源。
使用场景：
1、系统中存在大量的相似对象时，可以选择享元模式提高资源利用率。咖啡订购平台比较小，若假设一个电商平台，每个买家和卖家建立起买卖关系后，买家对象和卖家对象都是占用资源的。如果一个卖家同时与多个买家建立起买卖关系呢？此时享元模式的优势就体现出来了；
2、需要缓冲池的场景中，可以使用享元模式。如进程池，线程池等技术，就可以使用享元模式（事实上，很多的池技术中已经使得了享元模式）。
四、享元模式的缺点
1、享元模式虽然节约了系统资源，但同时也提高了系统的复杂性，尤其当遇到外部状态和内部状态混在一起时，需要先将其进行分离，才可以使用享元模式。否则，会引起逻辑混乱或业务风险；
2、享元模式中需要额外注意线程安全问题。
桥梁模式
一、画笔与形状
在介绍原型模式的一节中，我们举了个图层的例子，这一小节内容，我们同样以类似画图的例子，说明一种结构类设计模式：桥梁模式。
在一个画图程序中，常会见到这样的情况：有一些预设的图形，如矩形、圆形等，还有一个对象-画笔，调节画笔的类型（如画笔还是画刷，还是毛笔效果等）并设定参数（如颜色、线宽等），选定图形，就可以在画布上画出想要的图形了。要实现以上需求，先从最抽象的元素开始设计，即形状和画笔（暂时忽略画布，同时忽略画笔参数，只考虑画笔类型）。
class Shape:
name=""
param=""
def __init__(self,*param):
pass
def getName(self):
return self.name
def getParam(self):
return self.name,self.param
class 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.param
class 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:10cm
Create a circle:Radius:15cm
DRAWING Normal Line:Rectangle----PARAMS:('Rectangle', 'Long:20cm Width10cm')
DRAWING Brush Line:Circle----PARAMS:('Circle', 'Radius:15cm')
二、桥梁模式
桥梁模式又叫桥接模式，定义如下：将抽象与实现解耦（注意此处的抽象和实现，并非抽象类和实现类的那种关系，而是一种角色的关系，这里需要好好区分一下），可以使其独立变化。在形如上例中，Pen只负责画，但没有形状，它终究是不知道要画什么的，所以我们把它叫做抽象化角色；而Shape是具体的形状，我们把它叫做实现化角色。抽象化角色和实现化角色是解耦的，这也就意味着，所谓的桥，就是抽象化角色的抽象类和实现化角色的抽象类之间的引用关系。
三、桥梁模式的优点和应用场景
优点：
1、抽象角色与实现角色相分离，二者可以独立设计，不受约束；
2、扩展性强：抽象角色和实现角色可以非常灵活地扩展。
应用场景：
1、不适用继承或者原继承关系中抽象类可能频繁变动的情况，可以将原类进行拆分，拆成实现化角色和抽象化角色。例如本例中，若将形状、粗细、绘画样式等属于汇集在一个类中，一旦抽象类中有所变动，将造成巨大的风险；
2、重用性比较大的场景。比如开关控制逻辑的程序，开关就是抽象化角色，开关的形式有很多种，操作的实现化角色也有很多种，采用桥梁模式，（如当前例子）开关即可进行复用，整体会将设计的粒度减小。
四、桥梁模式的缺点
1、增加对系统理解的难度。