设计模式(Design pattern)是一套被反复使用、多数人知晓的、通过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、html
保证代码可靠性。 毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,设计模式是软件工程的基石,如同大厦的一块块砖石同样。python
项目中合理的运用设计模式能够完美的解决不少问题,每种模式在如今中都有相应的原理来与之对应,每个模式描述了一个在咱们周围不断重复发生的问题,程序员
以及该问题的核心解决方案,这也是它能被普遍应用的缘由。算法
前面讲过,社会化的分工愈来愈细,天然在软件设计方面也是如此,所以对象的建立和对象的使用分开也就成为了必然趋势。由于对象的建立会消耗掉系统的不少资源,因此单独对对象的建立进行研究,从而可以高效地建立对象就是建立型模式要探讨的问题。这里有6个具体的建立型模式可供研究,它们分别是:spring
简单工厂模式(Simple Factory); 工厂方法模式(Factory Method); 抽象工厂模式(Abstract Factory); 建立者模式(Builder); 原型模式(Prototype); 单例模式(Singleton)。
说明:严格来讲,简单工厂模式不是GoF总结出来的23种设计模式之一。编程
在解决了对象的建立问题以后,对象的组成以及对象之间的依赖关系就成了开发人员关注的焦点,由于如何设计对象的结构、继承和依赖关系会影响到后续程序的维护性、代码的健壮性、耦合性等。对象结构的设计很容易体现出设计人员水平的高低,这里有7个具体的结构型模式可供研究,它们分别是:设计模式
外观模式(Facade); 适配器模式(Adapter); 代理模式(Proxy); 装饰模式(Decorator); 桥模式(Bridge); 组合模式(Composite); 享元模式(Flyweight)
在对象的结构和对象的建立问题都解决了以后,就剩下对象的行为问题了,若是对象的行为设计的好,那么对象的行为就会更清晰,它们之间的协做效率就会提升,这里有11个具体的行为型模式可供研究,它们分别是:安全
模板方法模式(Template Method); 观察者模式(Observer); 状态模式(State); 策略模式(Strategy); 职责链模式(Chain of Responsibility); 命令模式(Command); 访问者模式(Visitor); 调停者模式(Mediator); 备忘录模式(Memento); 迭代器模式(Iterator); 解释器模式(Interpreter)。
开闭原则就是说对扩展开放,对修改关闭。在程序须要进行拓展的时候,不能去修改原有的代码,实现一个热插拔的效果。因此一句话归纳就是:微信
为了使程序的扩展性好,易于维护和升级。想要达到这样的效果,咱们须要使用接口和抽象类,后面的具体设计中咱们会提到这点。架构
里氏代换原则(Liskov Substitution Principle LSP)面向对象设计的基本原则之一。 里氏代换原则中说,任何基类能够出现的地方,子类必定能够出现。
LSP是继承复用的基石,只有当衍生类能够替换掉基类,软件单位的功能不受到影响时,基类才能真正被复用,而衍生类也可以在基类的基础上增长新的行为。
里氏代换原则是对“开-闭”原则的补充。实现“开-闭”原则的关键步骤就是抽象化。而基类与子类的继承关系就是抽象化的具体实现,
因此里氏代换原则是对实现抽象化的具体步骤的规范。
这个是开闭原则的基础,具体内容:是对接口编程,依赖于抽象而不依赖于具体。
这个原则的意思是:使用多个隔离的接口,比使用单个接口要好。仍是一个下降类之间的耦合度的意思,从这儿咱们看出,其实设计模式就是一个软件的设计思想,
从大型软件架构出发,为了升级和维护方便。因此上文中屡次出现:下降依赖,下降耦合。
一个实体应当尽可能少的与其余实体之间发生相互做用,使得系统功能模块相对独立。
原则是尽可能使用合成/聚合的方式,而不是使用继承。
工厂模式(Factory Pattern)是 Java 中最经常使用的设计模式之一。这种类型的设计模式属于建立型模式,它提供了一种建立对象的最佳方式。
在工厂模式中,咱们在建立对象时不会对客户端暴露建立逻辑,而且是经过使用一个共同的接口来指向新建立的对象。
意图: 定义一个用于建立对象的接口,让子类决定实例化哪个类。Factory Method 使一个类的实例化延迟到其子类。 适用性: 当一个类不知道它所必须建立的对象的类的时候。 当一个类但愿由它的子类来指定它所建立的对象的时候。 当类将建立对象的职责委托给多个子类中的某一个。
class ShapeFactory(object): '''工厂类''' def getShape(self): return self.shape_name class Circle(ShapeFactory): def __init__(self): self.shape_name = "Circle" def draw(self): print('draw circle') class Rectangle(ShapeFactory): def __init__(self): self.shape_name = "Retangle" def draw(self): print('draw Rectangle') class Shape(object): '''接口类,负责决定建立哪一个ShapeFactory的子类''' def create(self, shape): if shape == 'Circle': return Circle() elif shape == 'Rectangle': return Rectangle() else: return None fac = Shape() obj = fac.create('Circle') obj.draw() obj.getShape() 简单工厂
优势:客户端不须要修改代码。
缺点: 当须要增长新的运算类的时候,不只需新加运算类,还要修改工厂类,违反了开闭原则。
这个和简单工厂有区别,简单工厂模式只有一个工厂,工厂方法模式对每个产品都有相应的工厂
好处:增长一个运算类(例如N次方类),只须要增长运算类和相对应的工厂,两个类,不须要修改工厂类。
缺点:增长运算类,会修改客户端代码,工厂方法只是把简单工厂的内部逻辑判断移到了客户端进行。
class ShapeFactory(object): '''工厂类''' def getShape(self): return self.shape_name class Circle(ShapeFactory): def __init__(self): self.shape_name = "Circle" def draw(self): print('draw circle') class Rectangle(ShapeFactory): def __init__(self): self.shape_name = "Retangle" def draw(self): print('draw Rectangle') class ShapeInterfaceFactory(object): '''接口基类''' def create(self): '''把要建立的工厂对象装配进来''' raise NotImplementedError class ShapeCircle(ShapeInterfaceFactory): def create(self): return Circle() class ShapeRectangle(ShapeInterfaceFactory): def create(self): return Rectangle() shape_interface = ShapeCircle() obj = shape_interface.create() obj.getShape() obj.draw() shape_interface2 = ShapeRectangle() obj2 = shape_interface2.create() obj2.draw()
每个模式都是针对必定问题的解决方案。抽象工厂模式与工厂方法模式的最大区别就在于,工厂方法模式针对的是一个产品等级结构;
而抽象工厂模式则须要面对多个产品等级结构。
抽象工厂模式是对象的建立模式,它是工厂方法模式的进一步推广。
经过使用抽象工厂模式,能够处理具备相同(或者类似)等级结构中的多个产品族中的产品对象的建立问题
因为这两个产品族的等级结构相同,所以使用同一个工厂族也能够处理这两个产品族的建立问题,这就是抽象工厂模式。
抽象工厂的功能是为一系列相关对象或相互依赖的对象建立一个接口。必定要注意,这个接口内的方法不是任意堆砌的,而是一系列相关或相互依赖的方法。
好比上面例子中的主板和CPU,都是为了组装一台电脑的相关对象。不一样的装机方案,表明一种具体的电脑系列。
1.一个系统不该当依赖于产品类实例如何被建立、组合和表达的细节,这对于全部形态的工厂模式都是重要的。
2.这个系统的产品有多于一个的产品族,而系统只消费其中某一族的产品。
3.同属于同一个产品族的产品是在一块儿使用的,这一约束必须在系统的设计中体现出来。(好比:Intel主板必须使用Intel CPU、Intel芯片组)
4.系统提供一个产品类的库,全部的产品以一样的接口出现,从而使客户端不依赖于实现。
客户端使用抽象工厂来建立须要的对象,而客户端根本就不知道具体的实现是谁,客户端只是面向产品的接口编程而已。也就是说,客户端从具体的产品实现中解耦。
由于一个具体的工厂实现表明的是一个产品族,好比上面例子的从Intel系列到AMD系列只须要切换一下具体工厂。
若是须要给整个产品族添加一个新的产品,那么就须要修改抽象工厂,这样就会致使修改全部的工厂实现类。
class AbstractFactory(object): computer_name = '' def createCpu(self): pass def createMainboard(self): pass class IntelFactory(AbstractFactory): computer_name = 'Intel I7-series computer ' def createCpu(self): return IntelCpu('I7-6500') def createMainboard(self): return IntelMainBoard('Intel-6000') class AmdFactory(AbstractFactory): computer_name = 'Amd 4 computer ' def createCpu(self): return AmdCpu('amd444') def createMainboard(self): return AmdMainBoard('AMD-4000') class AbstractCpu(object): series_name = '' instructions = '' arch='' class IntelCpu(AbstractCpu): def __init__(self,series): self.series_name = series class IntelCpu(AbstractCpu): def __init__(self,series): self.series_name = series class AmdCpu(AbstractCpu): def __init__(self,series): self.series_name = series class AbstractMainboard(object): series_name = '' class IntelMainBoard(AbstractMainboard): def __init__(self,series): self.series_name = series class AmdMainBoard(AbstractMainboard): def __init__(self,series): self.series_name = series class ComputerEngineer(object): def makeComputer(self,computer_obj): self.prepareHardwares(computer_obj) def prepareHardwares(self,computer_obj): self.cpu = computer_obj.createCpu() self.mainboard = computer_obj.createMainboard() info = '''------- computer [%s] info: cpu: %s mainboard: %s -------- End -------- '''% (computer_obj.computer_name,self.cpu.series_name,self.mainboard.series_name) print(info) if __name__ == "__main__": engineer = ComputerEngineer() computer_factory = IntelFactory() engineer.makeComputer(computer_factory) computer_factory2 = AmdFactory() engineer.makeComputer(computer_factory2)
意图: 将一个复杂对象的构建与它的表示分离,使得一样的构建过程能够建立不一样的表示。 适用性: 当建立复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。 当构造过程必须容许被构造的对象有不一样的表示时。
#建造者模式 #相关模式:思路和模板方法模式很像,模板方法是封装算法流程,对某些细节,提供接口由子类修改,建造者模式更为高层一点,将全部细节都交由子类实现。 # 建造者模式:将一个复杂对象的构建与他的表示分离,使得一样的构建过程能够建立不一样的表示。 # 基本思想 # 某类产品的构建由不少复杂组件组成; # 这些组件中的某些细节不一样,构建出的产品表象会略有不一样; # 经过一个指挥者按照产品的建立步骤来一步步执行产品的建立; # 当须要建立不一样的产品时,只须要派生一个具体的建造者,重写相应的组件构建方法便可。 def printInfo(info): print(info) #建造者基类 class PersonBuilder(): def BuildHead(self): pass def BuildBody(self): pass def BuildArm(self): pass def BuildLeg(self): pass #胖子 class PersonFatBuilder(PersonBuilder): type = '胖子' def BuildHead(self): printInfo("构建%s的头" % self.type) def BuildBody(self): printInfo("构建%s的身体" % self.type) def BuildArm(self): printInfo("构建%s的手" % self.type) def BuildLeg(self): printInfo("构建%s的脚" % self.type) #瘦子 class PersonThinBuilder(PersonBuilder): type = '瘦子' def BuildHead(self): printInfo("构建%s的头" % self.type) def BuildBody(self): printInfo("构建%s的身体" % self.type) def BuildArm(self): printInfo("构建%s的手" % self.type) def BuildLeg(self): printInfo("构建%s的脚" % self.type) #指挥者 class PersonDirector(): pb = None; def __init__(self, pb): self.pb = pb def CreatePereson(self): self.pb.BuildHead() self.pb.BuildBody() self.pb.BuildArm() self.pb.BuildLeg() def clientUI(): pb = PersonThinBuilder() pd = PersonDirector(pb) pd.CreatePereson() pb = PersonFatBuilder() pd = PersonDirector(pb) pd.CreatePereson() return if __name__ == '__main__': clientUI();
意图: 保证一个类仅有一个实例,并提供一个访问它的全局访问点。 适用性: 当类只能有一个实例并且客户能够从一个众所周知的访问点访问它时。 当这个惟一实例应该是经过子类化可扩展的,而且客户应该无需更改代码就能使用一个扩展的实例时。
#实现__new__方法 #并在将一个类的实例绑定到类变量_instance上, #若是cls._instance为None说明该类尚未实例化过,实例化该类,并返回 #若是cls._instance不为None,直接返回cls._instance class Singleton(object): def __new__(cls, *args, **kwargs): if not hasattr(cls,'_instance'): orig = super(Singleton,cls) cls._instance = orig.__new__(cls) return cls._instance class MyClass(Singleton): def __init__(self,name): self.name = name a = MyClass("Alex") b = MyClass("Jack") print(a.name) print(b.name)
意图 将一个类的接口转换成客户但愿的另一个接口。Adapter 模式使得本来因为接口不兼容而不能一块儿工做的那些类能够一块儿工做。 适用性: 你想使用一个已经存在的类,而它的接口不符合你的需求。 你想建立一个能够复用的类,该类能够与其余不相关的类或不可预见的类(即那些接口可能不必定兼容的类)协同工做
# 适配器模式 # 将一个类的接口转换成客户但愿的另一个接口。使得本来因为接口不兼容而不能一块儿工做的那些类能够一块儿工做。 # 应用场景:但愿复用一些现存的类,可是接口又与复用环境要求不一致。 def printInfo(info): print(info) # 球员类 class Player(): name = '' def __init__(self,name): self.name = name def Attack(self,name): pass def Defense(self): pass # 前锋 class Forwards(Player): def __init__(self,name): Player.__init__(self,name) def Attack(self): printInfo("前锋%s 进攻" % self.name) def Defense(self,name): printInfo("前锋%s 防守" % self.name) # 中锋(目标类) class Center(Player): def __init__(self,name): Player.__init__(self,name) def Attack(self): printInfo("中锋%s 进攻" % self.name) def Defense(self): printInfo("中锋%s 防守" % self.name) # 后卫 class Guards(Player): def __init__(self,name): Player.__init__(self,name) def Attack(self): printInfo("后卫%s 进攻" % self.name) def Defense(self): printInfo("后卫%s 防守" % self.name) # 外籍中锋(待适配类) # 中锋 class ForeignCenter(Player): name = '' def __init__(self,name): Player.__init__(self,name) def ForeignAttack(self): printInfo("外籍中锋%s 进攻" % self.name) def ForeignDefense(self): printInfo("外籍中锋%s 防守" % self.name) # 翻译(适配类) class Translator(Player): foreignCenter = None def __init__(self,name): self.foreignCenter = ForeignCenter(name) def Attack(self): self.foreignCenter.ForeignAttack() def Defense(self): self.foreignCenter.ForeignDefense() def clientUI(): b = Forwards('巴蒂尔') m = Guards('姚明') ym = Translator('麦克格雷迪') b.Attack() m.Defense() ym.Attack() ym.Defense() return if __name__ == '__main__': clientUI()
意图: 将抽象部分与实现部分分离,使它们均可以独立的变化。 ——《设计模式》GOF 效果及实现要点: 1.Bridge模式使用“对象间的组合关系”解耦了抽象和实现之间固有的绑定关系,使得抽象和实现能够沿着各自的维度来变化。 2.所谓抽象和实现沿着各自维度的变化,即“子类化”它们,获得各个子类以后,即可以任意它们,从而得到不一样路上的不一样汽车。 3.Bridge模式有时候相似于多继承方案,可是多继承方案每每违背了类的单一职责原则(即一个类只有一个变化的缘由),复用性比较差。Bridge模式是比多继承方案更好的解决方法。 4.Bridge模式的应用通常在“两个很是强的变化维度”,有时候即便有两个变化的维度,可是某个方向的变化维度并不剧烈——换言之两个变化不会致使纵横交错的结果,并不必定要使用Bridge模式。 适用性: 在如下的状况下应当使用桥梁模式: 1.若是一个系统须要在构件的抽象化角色和具体化角色之间增长更多的灵活性,避免在两个层次之间创建静态的联系。 2.设计要求实现化角色的任何改变不该当影响客户端,或者说实现化角色的改变对客户端是彻底透明的。 3.一个构件有多于一个的抽象化角色和实现化角色,系统须要它们之间进行动态耦合。 4.虽然在系统中使用继承是没有问题的,可是因为抽象化角色和具体化角色须要独立变化,设计要求须要独立管理这二者。 总结: Bridge模式是一个很是有用的模式,也很是复杂,它很好的符合了开放-封闭原则和优先使用对象,而不是继承这两个面向对象原则
class AbstractRoad(object): '''公路基类''' car = None class AbstractCar(object): '''车辆基类''' def run(self): pass class Street(AbstractRoad): '''市区街道''' def run(self): self.car.run() print("在市区街道上行驶") class SpeedWay(AbstractRoad): '''高速公路''' def run(self): self.car.run() print("在高速公路上行驶") class Car(AbstractCar): '''小汽车''' def run(self): print("小汽车在") class Bus(AbstractCar): '''公共汽车''' def run(self): print("公共汽车在") if __name__ == "__main__": #小汽车在高速上行驶 road1 = SpeedWay() road1.car = Car() road1.run() # road2 = SpeedWay() road2.car = Bus() road2.run()
应用设计模式:
桥接模式(Bridge)来作(多维度变化);
结合上面的例子,增长一个维度"人",不一样的人开着不一样的汽车在不一样的路上行驶(三个维度);
结合上面增长一个类"人",并从新调用.
class AbstractRoad(object): '''公路基类''' car = None class AbstractCar(object): '''车辆基类''' def run(self): pass class Street(AbstractRoad): '''市区街道''' def run(self): self.car.run() print("在市区街道上行驶") class SpeedWay(AbstractRoad): '''高速公路''' def run(self): self.car.run() print("在高速公路上行驶") class Car(AbstractCar): '''小汽车''' def run(self): print("小汽车在") class Bus(AbstractCar): '''公共汽车''' def run(self): print("公共汽车在") if __name__ == "__main__": # 小汽车在高速上行驶 road1 = SpeedWay() road1.car = Car() road1.run() road2 = SpeedWay() road2.car = Bus() road2.run()
意图: 将对象组合成树形结构以表示“部分-总体”的层次结构。C o m p o s i t e 使得用户对单个对象和组合对象的使用具备一致性。 适用性: 你想表示对象的部分-总体层次结构。 你但愿用户忽略组合对象与单个对象的不一样,用户将统一地使用组合结构中的全部对象。
# 应用组合模式的会员卡消费 # # 那么咱们就根据咱们会员卡的消费,来模拟一下组合模式的实现吧!let's go! # # 首先: # # 1.咱们的部件有,总店,分店,加盟店! # # 2.咱们的部件共有的行为是:刷会员卡 # # 3.部件之间的层次关系,也就是店面的层次关系是,总店下有分店、分店下能够拥有加盟店。 # # 有了咱们这几个必要条件后,个人要求就是目前店面搞活动当我在总店刷卡后,就能够累积至关于在全部下级店面刷卡的积分总额,设计的代码以下 class Store(object): '''店面基类''' # 添加店面 def add(self, store): pass # 删除店面 def remove(self, store): pass def pay_by_card(self): pass class BranchStore(Store): def __init__(self, name): self.name = name self.my_store_list = [] def pay_by_card(self): print("店面[%s]的积分已累加进该会员卡" % self.name) for s in self.my_store_list: s.pay_by_card() # 添加店面 def add(self, store): self.my_store_list.append(store) # 删除店面 def remove(self, store): self.my_store_list.remove(store) class JoinStore(Store): '''加盟店''' def __init__(self,name): self.name = name def pay_by_card(self): print("店面[%s]的积分已累加进该会员卡" %self.name) def add(self,store): print("无添加子店权限") def remove(self,store): print("无删除子店权限") if __name__ == "__main__": store = BranchStore("朝阳总店") branch = BranchStore("海滨分店") join_branch = JoinStore("昌平加盟1店") join_branch2 = JoinStore("昌平加盟2店") branch.add(join_branch) branch.add(join_branch2) store.add(branch) store.pay_by_card() print(store.my_store_list)
意图: 为子系统中的一组接口提供一个一致的界面,Facade模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。 适用性: 当你要为一个复杂子系统提供一个简单接口时。子系统每每由于不断演化而变得愈来愈复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性,也更容易对子系统进行定制,但这也给那些不须要定制子系统的用户带来一些使用上的困难。Facade 能够提供一个简单的缺省视图,这一视图对大多数用户来讲已经足够,而那些须要更多的可定制性的用户能够越过facade层。 客户程序与抽象类的实现部分之间存在着很大的依赖性。引入facade 将这个子系统与客户以及其余的子系统分离,能够提升子系统的独立性和可移植性。 当你须要构建一个层次结构的子系统时,使用facade模式定义子系统中每层的入口点。若是子系统之间是相互依赖的,你可让它们仅经过facade进行通信,从而简化了它们之间的依赖关系。
# 外观模式(Facade),为子系统中的一组接口提供一个一致的界面,定义一个高层接口,这个接口使得这一子系统更加容易使用。 # 在如下状况下能够考虑使用外观模式: # (1)设计初期阶段,应该有意识的将不一样层分离,层与层之间创建外观模式。 # (2) 开发阶段,子系统愈来愈复杂,增长外观模式提供一个简单的调用接口。 # (3) 维护一个大型遗留系统的时候,可能这个系统已经很是难以维护和扩展,但又包含很是重要的功能,为其开发一个外观类,以便新系统与其交互。 # 优势编辑 # (1)实现了子系统与客户端之间的松耦合关系。 # (2)客户端屏蔽了子系统组件,减小了客户端所需处理的对象数目,并使得子系统使用起来更加容易。 def printInfo(info): print(info) class Stock(): name = '股票1' def buy(self): printInfo('买 '+self.name) def sell(self): printInfo('卖 '+self.name) class ETF(): name = '指数型基金' def buy(self): printInfo('买 '+self.name) def sell(self): printInfo('卖 '+self.name) class Future(): name = '期货' def buy(self): printInfo('买 '+self.name) def sell(self): printInfo('卖 '+self.name) class NationDebt(): name = '国债' def buy(self): printInfo('买 '+self.name) def sell(self): printInfo('卖 '+self.name) class Option(): name = '权证' def buy(self): printInfo('买 '+self.name) def sell(self): printInfo('卖 '+self.name) # 基金 class Fund(): def __init__(self): self.stock = Stock() self.etf = ETF() self.future = Future() self.debt = NationDebt() self.option = Option() def buyFund(self): self.stock.buy() self.etf.buy() self.debt.buy() self.future.buy() self.option.buy() def sellFund(self): self.stock.sell() self.etf.sell() self.future.sell() self.debt.sell() self.option.sell() def clientUI(): myFund = Fund() myFund.buyFund() myFund.sellFund() return if __name__ == '__main__': clientUI();
意图: 运用共享技术有效地支持大量细粒度的对象。 适用性: 一个应用程序使用了大量的对象。 彻底因为使用大量的对象,形成很大的存储开销。 对象的大多数状态均可变为外部状态。 若是删除对象的外部状态,那么能够用相对较少的共享对象取代不少组对象。 应用程序不依赖于对象标识。因为Flyweight 对象能够被共享,对于概念上明显有别的对象,标识测试将返回真值。
# Flyweight模式,顾名思义,就是共享元数据 # 在咱们面向对象设计过程当中,咱们经常会面临着对象实例过多的问题,若是对象实例过多这将是咱们系统性能提升的一个瓶颈。 # 假设咱们要设计一个星空场景,如今咱们须要实例星星对象,咱们能够实例每一颗星星,但随着咱们实例星星对象增多整个场景就愈来愈慢了, # 若是你实例了1000+颗星星要你去维护,这但是一个吃力不讨好的工做。咱们必须找到一个合适的方法解决以上问题,这就是今天要介绍的享元模式(Flyweight)。 # 享元模式(Flyweight):运用共享的技术有效地支持大量细粒度的对象。 # # 抽象享元角色(Flyweight):此角色是全部的具体享元类的超类,为这些类规定出须要实现的公共接口或抽象类。那些须要外部状态(External State)的操做能够经过方法的参数传入。抽象享元的接口使得享元变得可能,可是并不强制子类实行共享,所以并不是全部的享元对象都是能够共享的。 # # 具体享元(ConcreteFlyweight)角色:实现抽象享元角色所规定的接口。若是有内部状态的话,必须负责为内部状态提供存储空间。享元对象的内部状态必须与对象所处的周围环境无关,从而使得享元对象能够在系统内共享。有时候具体享元角色又叫作单纯具体享元角色,由于复合享元角色是由单纯具体享元角色经过复合而成的。 # # 复合享元(UnsharableFlyweight)角色:复合享元角色所表明的对象是不能够共享的,可是一个复合享元对象能够分解成为多个自己是单纯享元对象的组合。复合享元角色又称作不可共享的享元对象。这个角色通常不多使用。 # # 享元工厂(FlyweightFactoiy)角色:本角色负责建立和管理享元角色。本角色必须保证享元对象能够被系统适当地共享。当一个客户端对象请求一个享元对象的时候,享元工厂角色须要检查系统中是否已经有一个符合要求的享元对象,若是已经有了,享元工厂角色就应当提供这个已有的享元对象;若是系统中没有一个适当的享元对象的话,享元工厂角色就应当建立一个新的合适的享元对象。 # # 客户端(Client)角色:本角色还须要自行存储全部享元对象的外部状态。 # # 内部状态与外部状态:在享元对象内部而且不会随着环境改变而改变的共享部分,能够称之为享元对象的内部状态,反之随着环境改变而改变的,不可共享的状态称之为外部状态。 class FlyweightBase(object): _instances = dict() def __init__(self,*args,**kwargs): # 继承的子类必须初始化 raise NotImplementedError def __new__(cls, *args, **kwargs): # print(cls._instances,type(cls)) return cls._instances.setdefault( (cls,args,tuple(kwargs.items())), super(FlyweightBase,cls).__new__(cls) ) def test_data(self): pass class Spam(FlyweightBase): '''精子类''' def __init__(self,a,b): self.a = a self.b = b def test_data(self): print("精子准备好了",self.a,self.b) class Egg(FlyweightBase): '''卵类''' def __init__(self,x,y): self.x = x self.y = y def test_data(self): print("卵子准备好了",self.x,self.y) spam1 = Spam(1,'abc') spam2 = Spam(1,'abc') spam3 = Spam(3,'DEF') egg1 = Egg(1,'abc') # egg2 = Egg(4,'abc') assert spam1 is spam2 assert egg1 is not spam1 print(id(spam1),id(spam2)) spam2.test_data() egg1.test_data() print(egg1._instances) print(egg1._instances.keys())
意图:为其余对象提供一种代理以控制对这个对象的访问。 主要解决:在直接访问对象时带来的问题,好比说:要访问的对象在远程的机器上。在面向对象系统中,有些对象因为某些缘由(好比对象建立开销很大,或者某些操做须要安全控制,或者须要进程外的访问),直接访问会给使用者或者系统结构带来不少麻烦,咱们能够在访问此对象时加上一个对此对象的访问层。 什么时候使用:想在访问一个类时作一些控制。 如何解决:增长中间层。 关键代码:实现与被代理类组合。 应用实例: 一、Windows 里面的快捷方式。 二、猪八戒去找高翠兰结果是孙悟空变的,能够这样理解:把高翠兰的外貌抽象出来,高翠兰本人和孙悟空都实现了这个接口,
猪八戒访问高翠兰的时候看不出来这个是孙悟空,因此说孙悟空是高翠兰代理类。 三、买火车票不必定在火车站买,也能够去代售点。 四、一张支票或银行存单是帐户中资金的代理。
支票在市场交易中用来代替现金,并提供对签发人帐号上资金的控制。 五、spring aop。 优势: 一、职责清晰。 二、高扩展性。 三、智能化。 缺点: 一、因为在客户端和真实主题之间增长了代理对象,所以有些类型的代理模式可能会形成请求的处理速度变慢。 二、实现代理模式须要额外的工做,有些代理模式的实现很是复杂。 使用场景:按职责来划分,一般有如下使用场景: 一、远程代理。 二、虚拟代理。 三、Copy-on-Write 代理。 四、保护(Protect or Access)代理。 五、Cache代理。
六、防火墙(Firewall)代理。 七、同步化(Synchronization)代理。 八、智能引用(Smart Reference)代理。
# 应用特性:须要在通讯双方中间须要一些特殊的中间操做时引用,多加一个中间控制层。 # 结构特性:创建一个中间类,建立一个对象,接收一个对象,而后把二者联通起来 class sender_base: def __init__(self): pass def send_something(self, something): pass class send_class(sender_base): def __init__(self, receiver): self.receiver = receiver def send_something(self, something): print("SEND " + something + ' TO ' + self.receiver.name) class agent_class(sender_base): def __init__(self, receiver): self.send_obj = send_class(receiver) def send_something(self, something): self.send_obj.send_something(something) class receive_class: def __init__(self, someone): self.name = someone if '__main__' == __name__: receiver = receive_class('Alex') agent = agent_class(receiver) agent.send_something('agentinfo') print(receiver.__class__) print(agent.__class__)
在模板模式(Template Pattern)中,一个抽象类公开定义了执行它的方法的方式/模板。它的子类能够按须要重写方法实现,
但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
意图:定义一个操做中的算法的骨架,而将一些步骤延迟到子类中。模板方法使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。 主要解决:一些方法通用,却在每个子类都从新写了这一方法。 什么时候使用:有一些通用的方法。 如何解决:将这些通用算法抽象出来。 关键代码:在抽象类实现,其余步骤在子类实现。 应用实例: 一、在造房子的时候,地基、走线、水管都同样,只有在建筑的后期才有加壁橱加栅栏等差别。 二、西游记里面菩萨定好的 81 难,这就是一个顶层的逻辑骨架。
三、Spirng 中对 Hibernate 的支持,将一些已经定好的方法封装起来,好比开启事务、获取 Session、关闭 Session 等,程序员不重复写那些已经规范好的代码,直接丢一个实体就能够保存。 优势: 一、封装不变部分,扩展可变部分。 二、提取公共代码,便于维护。 三、行为由父类控制,子类实现。 缺点:每个不一样的实现都须要一个子类来实现,致使类的个数增长,使得系统更加庞大。 使用场景: 一、有多个子类共有的方法,且逻辑相同。 二、重要的、复杂的方法,能够考虑做为模板方法。
# 模板方法模式概述 # 在现实生活中,不少事情都包含几个实现步骤,例如请客吃饭,不管吃什么,通常都包含点单、吃东西、买单等几个步骤,一般状况下这几个步骤的次序是:点单 --> 吃东西 --> 买单。在这三个步骤中,点单和买单大同小异,最大的区别在于第二步——吃什么?吃面条和吃满汉全席可大不相同,如图1所示: # # 图1 请客吃饭示意图 # 在软件开发中,有时也会遇到相似的状况,某个方法的实现须要多个步骤(相似“请客”),其中有些步骤是固定的(相似“点单”和“买单”),而有些步骤并不固定,存在可变性(相似“吃东西”)。为了提升代码的复用性和系统的灵活性,可使用一种称之为模板方法模式的设计模式来对这类状况进行设计,在模板方法模式中,将实现功能的每个步骤所对应的方法称为基本方法(例如“点单”、“吃东西”和“买单”),而调用这些基本方法同时定义基本方法的执行次序的方法称为模板方法(例如“请客”)。在模板方法模式中,能够将相同的代码放在父类中,例如将模板方法“请客”以及基本方法“点单”和“买单”的实现放在父类中,而对于基本方法“吃东西”,在父类中只作一个声明,将其具体实现放在不一样的子类中,在一个子类中提供“吃面条”的实现,而另外一个子类提供“吃满汉全席”的实现。经过使用模板方法模式,一方面提升了代码的复用性,另外一方面还能够利用面向对象的多态性,在运行时选择一种具体子类,实现完整的“请客”方法,提升系统的灵活性和可扩展性。 # 模板方法模式定义以下: # 模板方法模式:定义一个操做中算法的框架,而将一些步骤延迟到子类中。模板方法模式使得子类能够不改变一个算法的结构便可重定义该算法的某些特定步骤。 # # Template Method Pattern: Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure. # 模板方法模式是一种基于继承的代码复用技术,它是一种类行为型模式。 # 模板方法模式是结构最简单的行为型设计模式,在其结构中只存在父类与子类之间的继承关系。经过使用模板方法模式,能够将一些复杂流程的实现步骤封装在一系列基本方法中,在抽象父类中提供一个称之为模板方法的方法来定义这些基本方法的执行次序,而经过其子类来覆盖某些步骤,从而使得相同的算法框架能够有不一样的执行结果。模板方法模式提供了一个模板方法来定义算法框架,而某些具体步骤的实现能够在其子类中完成。 # class Register(object): '''用户注册接口''' def register(self): pass def login(self): pass def auth(self): self.register() self.login() class RegisterByQQ(Register): '''qq注册''' def register(self): print("---用qq注册-----") def login(self): print('----用qq登陆-----') class RegisterByWeiChat(Register): '''微信注册''' def register(self): print("---用微信注册-----") def login(self): print('----用微信登陆-----') if __name__ == "__main__": register1 = RegisterByQQ() register1.login() register2 = RegisterByWeiChat() register2.login()
意图: 使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 适用性: 有多个的对象能够处理一个请求,哪一个对象处理该请求运行时刻自动肯定。 你想在不明确指定接收者的状况下,向多个对象中的一个提交一个请求。 可处理一个请求的对象集合应被动态指定。
# 职责链模式(Chain of Responsibility):使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。 # 适用场景: # 一、有多个的对象能够处理一个请求,哪一个对象处理该请求运行时刻自动肯定; # 二、在不明确指定接收者的状况下,向多个对象中的一个提交一个请求; # 三、处理一个请求的对象集合应被动态指定。 class BaseHandler(object): '''处理基类''' def successor(self,successor): # 与下一个责任者关联 self._successor = successor class RequestHandlerL1(BaseHandler): '''第一级请求处理者''' name = "TeamLeader" def handle(self,request): if request < 500: print("审批者[%s],请求金额[%s],审批结果[审批经过]"%(self.name,request)) else: print("\033[31;1m[%s]无权审批,交给下一个审批者\033[0m" %self.name) self._successor.handle(request) class RequestHandlerL2(BaseHandler): '''第二级请求处理者''' name = "DeptManager" def handle(self,request): if request < 5000 : print("审批者[%s],请求金额[%s],审批结果[审批经过]"%(self.name,request)) else: print("\033[31;1m[%s]无权审批,交给下一个审批者\033[0m" %self.name) self._successor.handle(request) class RequestHandlerL3(BaseHandler): '''第三级请求处理者''' name = "CEO" def handle(self, request): if request < 10000: print("审批者[%s],请求金额[%s],审批结果[审批经过]" % (self.name, request)) else: print("\033[31;1m[%s]要太多钱了,不批\033[0m" % self.name) # self._successor.handle(request) class RequestAPI(object): h1 = RequestHandlerL1() h2 = RequestHandlerL2() h3 = RequestHandlerL3() h1.successor(h2) h2.successor(h3) def __init__(self,name,amount): self.name = name self.amount = amount def handle(self): '''统一请求接口''' self.h1.handle(self.amount) if __name__ == "__main__": r1 = RequestAPI("Alex", 30000) r1.handle() print(r1.__dict__)
意图: 定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时, 全部依赖于它的对象都获得通知并被自动更新。 适用性: 当一个抽象模型有两个方面, 其中一个方面依赖于另外一方面。将这两者封装在独立的对象中以使它们能够各自独立地改变和复用。 当对一个对象的改变须要同时改变其它对象, 而不知道具体有多少对象有待改变。 当一个对象必须通知其它对象,而它又不能假定其它对象是谁。换言之, 你不但愿这些对象是紧密耦合的。
# 观察者(Observer)模式又名发布-订阅(Publish/Subscribe)模式 # 当咱们但愿一个对象的状态发生变化,那么依赖与它的全部对象都能相应变化(得到通知),那么就能够用到Observer模式, 其中的这些依赖对象就是观察者的对象,那个要发生变化的对象就是所谓’观察者’ class ObserverBase(object): '''观察者基类''' def __init__(self): self._observerd_list = [] def attach(self,observe_subject): ''' 添加要观察的对象 :param observe_subject: :return: ''' if observe_subject not in self._observerd_list: self._observerd_list.append(observe_subject) print("[%s]已经将[%s]加入观察队列..."%(self.name,observe_subject) ) def detach(self,observe_subject): ''' 解除观察关系 :param observe_subject: :return: ''' try: self._observerd_list.remove(observe_subject) print("再也不观察[%s]" %observe_subject) except ValueError: pass def notify(self): ''' 通知全部被观察者 :return: ''' for objserver in self._observerd_list: objserver.update(self) class Observer(ObserverBase): '''观察者类''' def __init__(self,name): super(Observer,self).__init__() self.name = name self._msg = '' @property def msg(self): ''' 当前情况 :return: ''' return self._msg @msg.setter def msg(self,content): self._msg = content self.notify() class GCDViewer(object): ''' 共军被观察者 ''' def update(self,observer_subject): print("共军:收到[%s]消息[%s] "%(observer_subject.name,observer_subject.msg) ) class GMDViewer(object): ''' 国军被观察者 ''' def update(self,observer_subject): print("国军:收到[%s]消息[%s] "%(observer_subject.name,observer_subject.msg) ) if __name__ == "__main__": observer1 = Observer("共军放哨者") observer2 = Observer("国军放哨者") gongjun1 = GCDViewer() guojun1 = GMDViewer() observer1.attach(gongjun1) observer1.attach(guojun1) observer2.attach(guojun1) observer1.msg = "\033[32;1m敌人来了...\033[0m" observer2.msg ="\033[31;1m前方发现敌人,请紧急撤离,不要告诉共军\033[0m"
意图:定义一系列的算法,把它们一个个封装起来, 而且使它们可相互替换。 主要解决:在有多种算法类似的状况下,使用 if...else 所带来的复杂和难以维护。 什么时候使用:一个系统有许多许多类,而区分它们的只是他们直接的行为。 如何解决:将这些算法封装成一个一个的类,任意地替换。 关键代码:实现同一个接口。 应用实例: 一、诸葛亮的锦囊妙计,每个锦囊就是一个策略。 二、旅行的出游方式,选择骑自行车、坐汽车,每一种旅行方式都是一个策略。
三、JAVA AWT 中的 LayoutManager。 优势: 一、算法能够自由切换。 二、避免使用多重条件判断。 三、扩展性良好。 缺点: 一、策略类会增多。 二、全部策略类都须要对外暴露。 使用场景: 一、若是在一个系统里面有许多类,它们之间的区别仅在于它们的行为,那么使用策略模式能够动态地让一个对象在许多行为中选择一种行为。
二、一个系统须要动态地在几种算法中选择一种。 三、若是一个对象有不少的行为,若是不用恰当的模式,这些行为就只好使用多重的条件选择语句来实现。
class TravelStrategy(object): ''' 出行策略 ''' def travelAlgorithm(self): pass class AirplaneStrategy(TravelStrategy): def travelAlgorithm(self): print("坐飞机出行....") class TrainStrategy(TravelStrategy): def travelAlgorithm(self): print("坐高铁出行....") class CarStrategy(TravelStrategy): def travelAlgorithm(self): print("自驾出行....") class BicycleStrategy(TravelStrategy): def travelAlgorithm(self): print("骑车出行....") class TravelInterface(object): def __init__(self,travel_strategy): self.travel_strategy = travel_strategy def set_strategy(self,travel_strategy): self.travel_strategy = travel_strategy def travel(self): return self.travel_strategy.travelAlgorithm() # 坐飞机 travel = TravelInterface(AirplaneStrategy()) travel.travel() # 改开车 travel.set_strategy(TrainStrategy()) travel.travel()
更多详见:http://www.cnblogs.com/alex3714/articles/5760582.html