23种设计模式对比与总结

设计模式总结:便于快速查看

 

前言：个人觉得设计模式就是各个对象在不同的时机、不同的调用方被创建，组合结构和封装的侧重点有些不同，从而形成了各个模式的概念。

 

1.      简单工厂模式

通过在工厂类中进行判断，然后创建需要的功能类。

优点：不必使用具体的功能类去创建该类的实例。缺点：新增一个功能类就需要在工厂类中增加一个判断。

 

2.      策略模式

假设一个功能类是一个策略，调用的时候需要创建这个策略的实例，传进一个类似策略控制中心的方法中，然后通过策略基类调用这个传进去的实例子类的方法。

优点：就是相对工厂模式免去了创建那个功能类的判断，简化了工厂模式。缺点：就是把子类实例赋值给了父类，这样就丢掉了子类新增的功能。

 

3.      工厂方法模式(属于工厂模式)

把简单工厂模式中的工厂类，做了进一步的抽象为接口或抽象类，给各个功能创建一个对应的工厂类，然后在这个工厂类里面去创建对应的实例。

缺点：当新增一个功能类，就需要创建对于的工厂类，相比简单工厂模式，免去了判断创建那个具体实例，但会创建过多的类，还不如策略模式。

 

4.      装饰模式

  一般情况下，当一个基类写好之后，我们也许不愿意去改动，也不能改动，原因是

   这样的在项目中用得比较久的基类，一旦改动，也许会影响其他功能模块，但是，

   又要在该类上面添加功能。使用继承，当在A阶段，写出继承类，用过一段时间，发

    现又要添加新功能，于是又要从原始类或A阶段的类继承，周而复始，慢慢的，子类就越来越多，层级就越来越深。然而，事实上，在C阶段需要A阶段的功能，但不需要B阶段的功能，在这种复杂情形下，继承就显得不灵活，于是想到了装饰模式。

    

     装饰模式：

     需要扩展一个类的功能，或给一个类增加附加责任

     需要动态地给一个对象增加功能，这些功能可以再动态地撤销。

     需要增加由一些基本功能的排列组合而产生的非常大量的功能，从而使继承关系变得不现实。

    

     在使用装饰模式前，需要了解虚方法和抽象方法的区别：虚方法，是实例方法，可以在子类中覆盖，也可以由该类对象直接调用。抽象方法需要写在抽象类中，抽象类不能实例化，所以要使用抽象方法必须由子类实现后方可调用。

    

     该模式中，要被扩展的类可以是包含抽象方法的抽象类，也可以是包含虚方法的实例类，也可以是普通实例类。装饰模式就是在原有基类上做扩展，至于基类是什么性质并不重要.

 

装饰模式在C#代码，和扩展方法，惊人的类似。

 

5.  代理模式

 代理类成为实际想调用对象的中间件，可以控制对实际调用对象的访问权限；维护实际调用对象的一个引用。

 

6.  原型模式

创建好了一个实例，然后用这个实例，通过克隆方式创建另一个同类型的实例，而不必关心这个新实例是如何创建的。

原型模式使用时需要注意浅拷贝与深拷贝的问题。

 

7.  建造者模式

每个对象都具备自己的功能，但是，它们的创建方式却是一样的。这个时候就需要中间这个建造者类来负责功能对象实例的创建。在调用端只需调用特定的方法即可。

这个和策略模式有点类似。

 

8.      抽象工厂模式

使用该功能类的功能类，利用抽象工厂去创建该功能类的实例。这样的好处在于尽可能的避免去创建功能的实例。

 

更牛逼的做法就是使用反射去创建这个功能类的实例，在调用端就一点都不需要知道要去实例化那个具体的功能类。这当然不是抽象工厂模式独有的。

 

9.      外观模式

外观模式：为外界调用提供一个统一的接口，把其他类中需要用到的方法提取出来，由外观类进行调用。然后在调用段实例化外观类，以间接调用需要的方法。这种方式形式上和代理模式有异曲同工之妙。

 

10.模板模式

模板模式：其实就是抽象出各个具体操作类的公共操作方法，在子类重新实现,然后使用子类去实例化父类。这个模板类其实可以使用接口替换。事实上接口才是专门用来定义操作规范。当然，当有些公共方法，各个子类均有一致需求，此时就不应使用接口，使用抽象类。

 

11.  状态模式

一个方法的判断逻辑太长，就不容易修改。方法过长，其本质就是，就是本类在不同条件下的状态转移。状态模式，就是将这些判断分开到各个能表示当前状态的独立类中。

 

12.  备忘录模式

备忘录模式：事实上我觉得这个东西没什么用，安照这种方式进行备份，会因为值类型与引用类型的不同而导致数据丢失。

 

13.  适配器模式

适配器模式：其实就是代理模式的一个变种，代码的编写方式都差不多。只是，使用这两种模式的出发点不一样，导致这两种模式产生了细微的差别。

 

14.   组合模式

当对象或系统之间出现部分与整体，或类似树状结构的情况时，考虑组合模式。相对装饰模式来说，这两个有异曲同工之妙，都强调对象间的组合，但是，装饰模式同时强调组合的顺序，而组合模式则是随意组合与移除。

 

15.  单例模式

能避免同一对象被反复实例化。比如说，访问数据库的连接对象就比普通对象实例化的时间要长;WCF中，维护服务器端远程对象的创建等，这类情况，很有必要用单例模式进行处理对象的实例化。

 

16.  迭代器模式

提供一种方法访问一个容器对象中各个元素，而又不需暴露该对象的内部细节。

Foreach就是这种模式应用的代表。

 

17.  职责链模式

职责链模式：就是一个将请求或命令进行转发的流程，类似工作流。并且，也非常类似状态模式，它们共同的特点就是将一个复杂的判断逻辑，转移到各个子类，然后在由子类进行简单判断。

 

状态模式与职责链模式的区别：状态模式是让各个状态对象自己知道其下一个处理的对象是谁，即在编译时便设定好了的；而职责链模式中的各个对象并不指定其下一个处理的对象到底是谁，只有在客户端才设定。

 

18.   命令模式

当有客户端发送了一系列的命令或请求，去要求某个对象实现什么操作，可使用命令模式，相当于多个命令发给一个对象。

 

这一点和观察者模式非常的类似。观察者模式也是某个对象，发出消息，然后由中间对象通知观察者然后去做什么，封装的是要执行操作的对象。而命令模式，则是将各个操作封装成类，然后告知某个对象该做什么。两者的区别是封装的角度不同。

 

19.   桥接模式

依据合成/聚合原则，优先使用类之间的不同组合，来实现各个类要表现的功能,而不是使用继承。比如说：继承会延续父类的功能，然而，并不是所有的子类都需要这样的功能，但是抽象出的东西在父类，导致子类又必须要实现它，这样，父类就越来越庞大，子类又多了很多不必要的东西。因此，桥接模式更强调类之间的组合从而实现解耦。

 

对比组合模式，它更强调的是部分与整体间的组合，桥接模式强调的是平行级别上不同类的组合。

 

20.  解释器模式

举例：写好了C#代码，VB代码，此时需要个编译器来编译。这时，这个编译器就相当于解释器，解释好了交给CPU执行。

 

解释器跟适配器模式有点类似，但是，适配器模式不需要预先知道要适配的规则，解释器是根据规则去执行解释。

21.  享元模式

享元模式其实是为了避免创建过多的数据对象。比如此列：在象棋中只有红黑双方，红棋子只是红棋中的一颗，很多红棋其实可以使用一个红棋对象表示即可，在外部只需公开该棋的状态即可区分那个红棋，从而达到减少内存消耗的目的。

 

22.中介者模式

中介者模式：中介者类唯一要干的事情就是给各个成员对象发出通知。因此，中介者事先就应该知道有哪些成员。

 

中介者模式和代理模式，观察者模式非常的像。但是其它两种模式在调用的时候，并不需要事先设置那个类被代理，或是事先那些对象需要被通知。

 

23. 访问者模式

在不改变原有代码的结构上，又想去影响原来的类，或是访问原来类的成员，此时就可以使用访问者模式。但需要注意的是：事先需要构造好那些要访问的对象的对象结构。这个结构在访问者类中去维护。

 

24. 观察者模式

就是消息订阅--发布模式。本来原始的状况是需要在观察者类内部设置需要通知的对象。结果现在出现了事件。定义委托来通知其他对象，显得更简洁。

 

转帖自：23种设计模式对比与总结