设计模式总结

实验：

创建型模式：工厂、单件

结构型模式：适配器、装饰、代理

行为型模式：命令、策略、观察者

 

重要   了解

 

设计模式组织分类

创建型模式：（对象的创建工作延迟到子类或者另一个对象中）

工厂模式、建造模式、原型模式、单例模式

 重点内容：工厂模式的意图和适用性。

结构型模式：（使用继承机制来组合类和对象）

适配器模式、桥接模式、组合模式、装饰模式、外观模式、轻量级模式、代理模式

重点内容：适配器模式、组合模式和装饰模式的意图和实现方法。

行为型模式：（使用继承了描述算法和控制流）

责任链模式、命令模式、观察者模式、策略模式、迭代器模式、模板方法模式、中介者模式

重点内容：策略模式与观察者模式的意图和实现方法。

设计原则

低耦合：类之间的关系降低

高内聚：类具有独立的责任

关系：相互矛盾的，低耦合势必导致低内聚、高内聚势必导致高耦合。

从技术角度考虑软件应具有较好的：可维护性、可扩展性、可重用性。

Open Closed Principle、里氏代换原则（LSP）、依赖倒置原则(DIP)、接口隔离原则（ISP）、合成/聚合复用原则（CARP）、迪米特法则（LoD）

创建型模式

简单工厂（simple factory pattern）

意图：   根据提供给它的数据，返回几个可能类中的一个类的实例。

优点：工厂类含有必要的判断逻辑，可以决定在什么时候创建哪一个产品类的实例，客户端可以免除直接创建产品对象的责任，而仅仅"消费"产品。实现了对责任的分割。

缺点：工厂类一旦不能正常工作，整个系统都要受影响；添加新产品要修改工厂类；静态，不可继承。

详细介绍连接：http://blog.csdn.net/weiwenlongll/article/details/6918164

工厂方法（factory method）

意图：   定义一个用于创建对象的接口，但让子类决定实例化哪一个类。工厂方法使一个类的实例化延迟到其子类。

 

 

 

 

 

 

 

 

 

 

前雾灯

 

 

 

适用性：       当一个类不知道他所必须创建的类的时候。

当一个类希望由它的子类来指定它所创建的对象的时候。

详细介绍连接：http://www.cnblogs.com/cbf4life/archive/2009/12/20/1628494.html

 

抽象工厂（abstract factory）

意图：   提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。指一个工厂等级结构可以创建出分属于不同产品等级结构的一个产品族中的所有对象。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

适用性：       一个系统不应当依赖于产品类实例如何被创建、组合和表达的细节，这对于所有形态的工厂模式都是重要的。

这个系统有多于一个的产品族，而系统只消费其中某一产品族。

同属于同一个产品族的产品是在一起使用的，这一约束必须在系统的设计中体现出来。（助记：所有男人（黑、白、黄）相同的生产线，男人女人不同的生产线）

系统提供一个产品类的库，所有的产品以同样的接口出现，从而使客户端不依赖于实现。

小编悟语：   concreteFactory就是挑选原生态不同等级结构中的产品，然后组装形成新的产品族。

与工厂方法的区别：工厂方法模式针对的是一个产品等级结构，而抽象工厂模式则针对的是多个产品等级结构。

详细介绍连接：http://www.cnblogs.com/cbf4life/archive/2009/12/23/1630612.html

 

 

简单工厂模式、工厂模式、抽象工厂模式之间的区别

工厂模式，也叫做说虚构造器，在简单工厂中间插入了一个具体产品工厂，这个工厂知道产品构造时候的具体细节，而简单工厂模式的产品具体构造细节是在一个个if/else分支，或者在switch/case分支里面的。工厂模式的好处就在于将工厂和产品之间的耦合降低，将具体产品的构造过程放在了具体工厂类里面。在以后扩展产品的时候方便很多，只需要添加一个工厂类，一个产品类，就能方便的添加产品，而不需要修改原有的代码。而在简单工厂中，如果要增加一个产品，则需要修改工厂类，增加if/else分支，或者增加一个case分支，工厂模式符合软件开发中的OCP原则（open closeprinciple），对扩展开放，对修改关闭。

 

抽象工厂模式：这个模式我总是感觉和builder模式非常相似。

工厂方法模式提供的是对一个产品的等级模式，，而抽象工厂方法提供的是对多个产品的等级模式，注意，这里的多个具体产品之间是相互耦合的，也就是说这里的抽象工厂提供的产品之间是存在某种联系的。

 

 

 

 

建造者模式（builder）

意图：   将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。

 

 

 

 

 

 

 

 

 

 

适用性：       当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。

当构造过程必须允许被构造的对象有不同的表示时。

优点：          建造者模式将一个复杂对象的生成责任作了很好的分配。它把构造过程放到指挥者的方法中，把装配过程放到具体建造者类中。

缺点：          如果产品之间的差异很大，这就需要借助工厂方法模式或抽象工厂模式。

如果产品的内部变化复杂，Builder的每一个子类都需要对应到不同的产品去做构建的动作、方法，这就需要定义很多个具体建造类来实现这种变化。

小编悟语：   在上图中bulider提供构件director对象的所有工作部件，director定义需要的工作部件和工作部件的启动顺序。

详细介绍连接：http://www.cnblogs.com/cbf4life/archive/2010/01/14/1647710.html

 

原型模式（prototype）

意图：   用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。

 

 

 

 

 

 

 

 

 

 

 

 

优点：   特别适用于创建对象成本较大的情况，系统如果需要重复利用，新的对象可以通过       原型模式对已有对象的属性进行复制并做修改来取得。

如果系统要保存对象的状态，而对象的状态变化很小，或者对象本身占内存不大的时候，也可以用原型模式配合备忘模式来应用。

缺点：   在实现深层复制时需要编写复杂的代码。

详细介绍连接：http://www.cnblogs.com/cbf4life/archive/2009/12/10/1621453.html

               http://www.cnblogs.com/cbf4life/archive/2009/12/10/1621471.html

单例模式（singleton pattern）

意图：   保证一个类仅有一个实例，并提供一个访问它的全局访问点。

 

 

 

 

 

 

 

适用性：       当类只能有一个实例而且客户可以从一个众所周知的访问点访问它时。

当这个唯一实例应该是通过子类化可扩展的，并且客户应该无需更改代码就能使用一个扩展的实例时。

优点：          为一个面对象的应用程序提供了对象惟一的访问点。

缺点：          Singleton对象类派生子类有很大困难，只有父类没有被实例化时才可以实现。

自动垃圾回收机制，对象长时间不被利用，系统会认为它是垃圾，自动回收它的资源。

详细介绍连接：http://www.cnblogs.com/cbf4life/archive/2009/12/18/1626850.html

 

 

创建型模式总结

生成创建对象类的子类，FactoryMethod模式。主要缺点是， 仅为了改变产品类，就可能需要创建一个新的子类。这样的改变可能是级联的。

更多的依赖于对象复合：定义一个对象负责明确产品对象的类，并将它作为该系统的参数。Abstract Factoy由这个工厂对象产生多个类的对象。Builder由这个对象使用一个相对复杂的协议，逐步创建一个复杂产品。Prototype由该工厂对象通过拷贝原型对象来创建产品对象。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

结构型模式

 

适配器模式（adapter pattern）

意图：   将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。

优点：          可以将一个类的接口和另一个类的接口匹配起来，使用的前提是不能或不想修改原来的被适配者接口。

缺点：          客户调用需要变动。

适用性：       对象需要利用现存的并且接口不兼容的类。

需要创建可重用的类以协作其他接口不一定兼容的类。

需要使用若干现存的子类但又不想派生这些子类的每一个接口。

详细介绍连接：http://www.cnblogs.com/wangjq/archive/2012/07/09/2582485.html

 

 

 

 

 

 

 

 

 

桥接模式（bridge pattern）

意图：   将抽象部分与它的实现部分分离，使它们都可以独立地变化。

抽象化：存在于多个实体中的共同的概念性联系，就是抽象化。作为一个过程，抽象化就是忽略一些信息，从而把不同的实体当做同样的实体对待。

实现化：抽象化给出的具体实现，就是实现化。

脱耦：

所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。

将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦，就是指在一个软件系统的抽象化和实现化之间使用组合/聚合关系而不是继承关系，从而使两者可以相对独立地变化。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

具体事例：

 

 

 

 

 

 

 

 

 

 

优点：          桥接模式可以从接口中分离实现功能，使得设计更具扩展性，这样，客户调用           方法时根本不需要知道实现的细节。

桥接模式减少了子类，假设程序要在2个操作系统中处理6种图像格式，纯粹的继承就需要(2*6)12个子类，而应用桥接模式，只需要(2+6)8个子类。它使得代码更清洁，生成的执行程序文件更小。

缺点：          桥接模式的缺陷是抽象类与实现类的双向连接使得运行速度减少。

详细介绍连接：http://www.cnblogs.com/houleixx/archive/2008/02/23/1078877.html

 

 

 

 

 

组合模式（composite pattern）

意图：   将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。

解决问题：解决整体与部分可以被一致对待问题。

优点：   组合模式可以清楚地定义分层次的复杂对象，表示对象的全部或部分层次，使得增       加新部件更加容易。

组合模式适用于树型结构，如ERP中的BOM。

缺点：   组合模式的缺点是使得设计变得更加抽象。

适用性：你想表示对象的部分-整体层次结构。

你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。

详细介绍连接：http://blog.csdn.net/xsxxxsxx/article/details/7218221

 

 

 

 

 

 

 

 

装饰模式（decorator pattern）

意图：   动态地给一个对象添加一些额外的职责。就增加功能来说，Decorator模式相比生成子类更为灵活。

 

 

 

 

 

 

 

 

 

 

 

 

 

小编悟语：concreteComponent是被装饰对象，decorator是具有装饰功能的装饰器，用于装饰concreteComponent。在此decorator继承component是为了获得component的类型，即成为component。这样就可以不用知道装饰品的具体类型，而在只知道下个装饰品是component对象的情况下，装饰上一个对象了。每次从decorator中传入的对象，即为“被装饰对象”。

优点：   装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承       更多的灵活性。

通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合。

缺点：   这种比继承更加灵活机动的特性，也同时意味着装饰模式比继承更加易于出错。

由于使用装饰模式，可以比使用继承关系需要较少数目的类。使用较少的类，当然使设       计比较易于进行。但是，在另一方面，使用装饰模式会产生比使用继承关系更多的对象。  更多的对象会使得查错变得困难，特别是这些对象看上去都很相像。

适用性：在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

处理那些可以撤消的职责。

当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展，为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

 

详细介绍连接：

http://www.cnblogs.com/rush/archive/2011/05/08/Decorator_DesignPattern_NETFramework.html

 

 

 

 

 

 

 

 

外观模式（facade pattern）

意图：   为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，

这个接口使得这一子系统更加容易使用。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

优点：   外观模式提供了一个简单且公用的接口去处理复杂的子系统，并且没有减少子系统       的功能。

遮蔽了子系统的复杂性，避免了客户与子系统直接连接，也减少了子系统与子系统间的连接，每个子系统都有它的Facade模式，每个子系统采用Facade模式去访问其他子系统。

缺点：   外观模式的劣势就是限制了客户的自由，减少了可变性。

适用性：需要为复杂的子系统提供一个简单的接口。

客户与抽象的实现类中存在若干依赖。

子系统分层是必要的或架构要求的情况下。

详细介绍连接：http://blog.csdn.net/shylanse/article/details/4303082

 

 

 

 

 

 

 

 

 

 

 

 

 

代理模式（proxy pattern）

意图：   为其他对象提供一种代理以控制对这个对象的访问。

优点： 当对象在远程机器上，要通过网络来生成时，速度可能会慢，此时用RemoteProxy       模式，可以掩护对象由网络生成的过程，系统的速度会加快。

对于大图片的加载，Virtual Proxy模式可以加载在后台运行，前台用的Proxy对象使得整体运行速度得到优化。

Protect Proxy可以验证对真实对象的引用权限。

详细介绍连接：http://www.cnblogs.com/cbf4life/archive/2010/01/27/1657438.html

 

行为型设计模式

 

责任链模式（chain of  responsibility pattern）

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

 

 

 

 

 

 

 

 

 

 

 

优点：          责任链模式可以减少对象的连接，为对象责任分配增加了很大的灵活性。该模           式允许把一组类当作一个类来使用，并且在类的组合中，一个类的事件可以发送到          另一个类来处理。

责任链还会以树状出现，这样一个事件可以传给多个类，或者多个类的信息提交给一个类。

缺点：          树状责任链能够提供更灵活的技巧，但缺点是信息在树中容易迷失。

适用性：       超过一个对象能够处理客户请求并且到底哪个对象处理预先不知道。

一个请求可以分布到多个对象但它的接收都不是清晰。

可以动态指定一组对象处理对象请求。

详细介绍连接：http://www.cnblogs.com/singlepine/archive/2005/10/30/265010.html

 

 

 

 

 

 

命令模式（command pattern）

意图：   将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。

 

 

 

 

 

 

 

 

 

 

注意点：发送请求的对象只需要知道如何发送请求，而不知道如何完成请求。

具体列子：

餐馆点菜

餐馆顾客点菜，顾客只需要向服务员下订单点菜，不需要知道哪个厨师做这个菜，顾客所要做的只是订单交给服务员就可以了。

小编悟语：invoker是顾客，发命令下菜单就行；receiver是厨师，知道做菜就行；其余的相当于服务员，要知道是什么命令，然后交由那个厨师去做。

优点：   命令模式分离了接受请求的对象与实现处理请求工作的对象，已经存在的对象可以       保持不变，使得增加新类的工作更简单。

命令模式还可以分离用户界面和业务对象，降低系统耦合度。

缺点：   最大缺陷是类的数量增加了，系统变得更复杂，程序的调试工作也相应变得困难。

适用性：当需要与动作有关的对象来作为参数。

需要在不同的时间创建请求，生成请求队列，执行请求。

需要支持取消、保存修改日志或处理事务功能。

需要支持宏命令。

详细介绍连接：http://www.cnblogs.com/sjms/archive/2010/07/09/1774069.html

 

 

 

 

 

 

迭代器模式（iterator pattern）

意图：   提供一种方法顺序访问一个聚合对象中各个元素, 而又不需暴露该对象的内部表示。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

优点：   迭代器简化了聚集的接口，因为迭代器提供了遍历接口，所以聚集就可以不用提供       遍历接口。

一个聚集可以提供多个迭代器，而且这些迭代器的迭代状态都是相互独立的，这样一个聚集可以在多个方法中被同时遍历。

缺点：   迭代器给客户端一个聚集被顺序化的错觉。

迭代器给出的聚集元素没有类型特征，统一都是Object。

适用性：访问一个聚合对象的内容而无需暴露它的内部表示。

支持对聚合对象的多种遍历。

为遍历不同的聚合结构提供一个统一的接口(即支持多态迭代)。

详细介绍连接：http://www.cnblogs.com/jqbird/archive/2011/08/31/2160653.html

 

 

观察者模式（observer pattern）

意图：   定义对象间的一种一对多的依赖关系,当一个对象的状态发生改变时,所有依赖于它的对象都得到通知并被自动更新。

 

 

 

 

 

 

 

 

 

 

 

优点：   观察者模式抽象了被观察者与观察者对象间的连接，提供了广播式的对象间通信，       并且容易增加新的观察者对象。

缺点：   观察者模式的缺陷是对象间的关系难易理解，在某种情况下会表现低效能。

适用性：当一个抽象模型有两个方面, 其中一个方面依赖于另一方面。将这二者封装在独立       的对象中以使它们可以各自独立地改变和复用。

当对一个对象的改变需要同时改变其它对象, 而不知道具体有多少对象有待改变。

当一个对象必须通知其它对象，而它又不能假定其它对象是谁。换言之, 你不希望这些对象是紧密耦合的。 

 

模板方法模式（templeate method pattern）

意图：   定义一个操作中算法的骨架(skeleton)，以将一些步骤延缓到子类中实现。模板方法让子类重新定义一个算法的某些步骤而无须改变算法的结构。

 

 

 

 

 

 

 

 

 

 

 

 

 

优点：   模板方法模式在一个类中形式化地定义算法，而由它的子类实现细节的处理。在子       类定义处理算法时不会改变算法的结构。

缺点：   每个不同的实现都需要定义一个子类。

适用性：想将相同的算法放在一个类中，将算法变化的部分放在子类中实现。

子类公共的算法应该放在一个公共的类中，避免代码重复。

 

策略模式（strategy pattern）

意图：   定义一系列的算法，将每一个算法封装起来，并让它们可以相互替换。策略模式让算法独立于使用它的客户而变化。

 

 

 

 

 

 

 

 

 

 

优点：   可以避免使用多重条件转移语句，系统变得更加灵活。

缺点：   会产生很多子类，符合高内聚的责任分配模式。

适用性：多个类的区别只是在于行为不同。

需要对行为的算法作很多变动。

客户不知道算法要使用的数据。