23种设计模式
⽬录
（⼯⼚⽅法）
clip_image001
意图：
定义⼀个⽤于创建对象的接⼝，让⼦类决定实例化哪⼀个类。Factory Method 使⼀个类的实例化延迟到其⼦类。
适⽤性：
当⼀个类不知道它所必须创建的对象的类的时候。
当⼀个类希望由它的⼦类来指定它所创建的对象的时候。
当类将创建对象的职责委托给多个帮助⼦类中的某⼀个，并且你希望将哪⼀个帮助⼦类是代理者这⼀信息局部化的时候。
（抽象⼯⼚）
clip_image002
意图：
提供⼀个创建⼀系列相关或相互依赖对象的接⼝，⽽⽆需指定它们具体的类。
适⽤性：
⼀个系统要独⽴于它的产品的创建、组合和表⽰时。
⼀个系统要由多个产品系列中的⼀个来配置时。
当你要强调⼀系列相关的产品对象的设计以便进⾏联合使⽤时。
当你提供⼀个产品类库，⽽只想显⽰它们的接⼝⽽不是实现时。
（建造者）
clip_image003
意图：
将⼀个复杂对象的构建与它的表⽰分离，使得同样的构建过程可以创建不同的表⽰。
适⽤性：
当创建复杂对象的算法应该独⽴于该对象的组成部分以及它们的装配⽅式时。
当构造过程必须允许被构造的对象有不同的表⽰时。
（原型）
clip_image004
意图：
⽤原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。
适⽤性：
单例模式的几种实现方式当要实例化的类是在运⾏时刻指定时，例如，通过动态装载；或者
为了避免创建⼀个与产品类层次平⾏的⼯⼚类层次时；或者
当⼀个类的实例只能有⼏个不同状态组合中的⼀种时。建⽴相应数⽬的原型并克隆它们可能⽐每次⽤合适的状态⼿⼯实例化该类更⽅便⼀些。
（单例）
clip_image005
意图：
保证⼀个类仅有⼀个实例，并提供⼀个访问它的全局访问点。
适⽤性：
当类只能有⼀个实例⽽且客户可以从⼀个众所周知的访问点访问它时。
当这个唯⼀实例应该是通过⼦类化可扩展的，并且客户应该⽆需更改代码就能使⽤⼀个扩展的实例时。
（适配器）
clip_image006
意图：
将⼀个类的接⼝转换成客户希望的另外⼀个接⼝。Adapter 模式使得原本由于接⼝不兼容⽽不能⼀起⼯作的那些类可以⼀起⼯作。
适⽤性：
你想使⽤⼀个已经存在的类，⽽它的接⼝不符合你的需求。
你想创建⼀个可以复⽤的类，该类可以与其他不相关的类或不可预见的类（即那些接⼝可能不⼀定兼容的类）协同⼯作。
（仅适⽤于对象Adapter ）你想使⽤⼀些已经存在的⼦类，但是不可能对每⼀个都进⾏⼦类化以匹配它们的接⼝。对象适配器可以适配它的⽗类接⼝。
（桥接）
意图：
将抽象部分与它的实现部分分离，使它们都可以独⽴地变化。
适⽤性：
你不希望在抽象和它的实现部分之间有⼀个固定的绑定关系。例如这种情况可能是因为，在程序运⾏
时刻实现部分应可以被选择或者切换。
类的抽象以及它的实现都应该可以通过⽣成⼦类的⽅法加以扩充。这时Bridge 模式使你可以对不同的抽象接⼝和实现部分进⾏组合，并分别对它们进⾏扩充。
对⼀个抽象的实现部分的修改应对客户不产⽣影响，即客户的代码不必重新编译。
（C++）你想对客户完全隐藏抽象的实现部分。在C++中，类的表⽰在类接⼝中是可见的。
有许多类要⽣成。这样⼀种类层次结构说明你必须将⼀个对象分解成两个部分。Rumbaugh 称这种类层次结构为“嵌套的普化”（nested generalizations ）。
你想在多个对象间共享实现（可能使⽤引⽤计数），但同时要求客户并不知道这⼀点。⼀个简单的例⼦便是Coplien 的String 类[ Cop92 ]，在这个类中多个对象可以共享同⼀个字符串表⽰（StringRep ）。
（组合）
clip_image008
意图：
将对象组合成树形结构以表⽰“部分-整体”的层次结构。C o m p o s i t e 使得⽤户对单个对象和组合对象的使⽤具有⼀致性。
适⽤性：
你想表⽰对象的部分-整体层次结构。
你希望⽤户忽略组合对象与单个对象的不同，⽤户将统⼀地使⽤组合结构中的所有对象。
（装饰）
意图：动态地给⼀个对象添加⼀些额外的职责。就增加功能来说，Decorator 模式相⽐⽣成⼦类更为灵活。适⽤性：
在不影响其他对象的情况下，以动态、透明的⽅式给单个对象添加职责。
处理那些可以撤消的职责。
当不能采⽤⽣成⼦类的⽅法进⾏扩充时。⼀种情况是，可能有⼤量独⽴的扩展，为⽀持每⼀种组合将产⽣⼤量的⼦类，使得⼦类数⽬呈爆炸性增长。另⼀种情况可能是因为类定义被隐藏，或类定义不能⽤于⽣成⼦类。
（外观）
clip_image010
意图：
为⼦系统中的⼀组接⼝提供⼀个⼀致的界⾯，Facade模式定义了⼀个⾼层接⼝，这个接⼝使得这⼀⼦系统更加容易使⽤。
适⽤性：
当你要为⼀个复杂⼦系统提供⼀个简单接⼝时。⼦系统往往因为不断演化⽽变得越来越复杂。⼤多数模式使⽤时都会产⽣更多更⼩的类。这使得⼦系统更具可重⽤性，也更容易对⼦系统进⾏定制，但这也给那些不需要定制⼦系统的⽤户带来⼀些使⽤上的困难。Facade 可以提供⼀个简单的缺省视图，这⼀视图对⼤多数⽤户来说已经⾜够，⽽那些需要更多的可定制性的⽤户可以越过facade层。
客户程序与抽象类的实现部分之间存在着很⼤的依赖性。引⼊facade 将这个⼦系统与客户以及其他的⼦系统分离，可以提⾼⼦系统的独⽴性和可移植性。
当你需要构建⼀个层次结构的⼦系统时，使⽤facade模式定义⼦系统中每层的⼊⼝点。如果⼦系统之间是相互依赖的，你可以让它们仅通过facade进⾏通讯，从⽽简化了它们之间的依赖关系。
（享元）

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。