23种设计模式对比与总结

设计模式 专栏收录该内容
25 篇文章 0 订阅

设计模式总结:

 

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

 

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. 观察者模式

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

 

  • 1
    点赞
  • 2
    评论
  • 1
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

主要是介绍各格式流行的软件设计模式,对于程序员的进一步提升起推进作用,有时间可以随便翻翻~~ 23种设计模式汇集 如果你还不了解设计模式是什么的话? 那就先看设计模式引言 ! 学习 GoF 设计模式的重要性 建筑和软件中模式之异同 A. 创建模式 设计模式之 Singleton(单态/单件) 阎宏博士讲解:单例(Singleton)模式 保证一个类只有一个实例,并提供一个访问它的全局访问点 设计模式之 Factory(工厂方法和抽象工厂) 使用工厂模式就象使用 new 一样频繁. 设计模式之 Builder 汽车由车轮 方向盘 发动机很多部件组成,同时,将这些部件组装成汽车也是一件复杂的工作,Builder 模式就是将这两 情况分开进行。 设计模式之 Prototype(原型) 用原型实例指定创建对象的类,并且通过拷贝这些原型创建新的对象。 B. 结构模式 设计模式之 Adapter(适配器) 使用类再生的两个方式:组合(new)和继承(extends),这个已经在 thinking in java中提到过. 设计模式之 Proxy(代理) 以 Jive 为例,剖析代理模式在用户级别授权机制上的应用 设计模式之 Facade(门面?) 可扩展的使用 JDBC针对不同的数据库编程,Facade提供了一灵活的实现. 设计模式之 Composite(组合) 就是将类用树形结构组合成一个单位.你向别人介绍你是某单位,你是单位中的一个元素,别人和你做买卖,相当于 和单位做买卖。文章中还对 Jive再进行了剖析。 设计模式之 Decorator(装饰器) Decorator 是个油漆工,给你的东东的外表刷上美丽的颜色. 设计模式之 Bridge(桥连) 将牛郎织女分开(本应在一起,分开他们,形成两个接口),在他们之间搭建一个桥(动态的结合) 设计模式之 Flyweight(共享元) 提供 Java运行性能,降低小而大量重复的类的开销. C. 行为模式 设计模式之 Command(命令) 什么是将行为封装,Command 是最好的说明. 设计模式之 Observer(观察者) 介绍如何使用 Java API 提供的现成 Observer 设计模式之 Iterator(迭代器) 这个模式已经被整合入Java的Collection.在大多数场合下无需自己制造一个Iterator,只要将对象装入Collection中, 直接使用 Iterator 进行对象遍历。 设计模式之 Template(模板方法) 实际上向你介绍了为什么要使用 Java 抽象类,该模式原理简单,使用很普遍. 设计模式之 Strategy(策略) 不同算法各自封装,用户端可随意挑选需要的算法. 设计模式之 Chain of Responsibility(责任链) 各司其职的类串成一串,好象击鼓传花,当然如果自己能完成,就不要推委给下一个. 设计模式之 Mediator(中介) Mediator 很象十字路口的红绿灯,每个车辆只需和红绿灯交互就可以. 设计模式之 State(状态) 状态是编程中经常碰到的实例,将状态对象化,设立状态变换器,便可在状态中轻松切换. 设计模式之 Memento(注释状态?) 很简单一个模式,就是在内存中保留原来数据的拷贝. 设计模式之 Interpreter(解释器) 主要用来对语言的分析,应用机会不多. 设计模式之 Visitor(访问者) 访问者在进行访问时,完成一系列实质性操作,而且还可以扩展. 设计模式引言 设计面向对象软件比较困难,而设计可复用的面向对象软件就更加困难。你必须找到相关的对象,以适当的粒度将它们归 类,再定义类的接口和继承层次,建立对象之间的基本关系。你的设计应该对手头的问题有针对性,同时对将来的问题和需求 也要有足够的通用性。 你也希望避免重复设计或尽可能少做重复设计。有经验的面向对象设计者会告诉你,要一下子就得到复用性和灵活性好的设计, 即使不是不可能的至少也是非常困难的。一个设计在最终完成之前常要被复用好几次,而且每一次都有所修改。 有经验的面向对象设计者的确能做出良好的设计,而新手则面对众多选择无从下手,总是求助于以前使用过的非面向对象 技术。新手需要花费较长时间领会良好的面向对象设计是怎么回事。有经验的设计者显然知道一些新手所不知道的东西,这又 是什么呢? 内行的设计者知道:不是解决任何问题都要从头做起。他们更愿意复用以前使用过的解决方案。当找到一个好的解决方案,他 们会一遍又一遍地使用。这些经验是他们成为内行的部分原因。因此,你会在许多面向对象系统中看到类和相互通信的对象( c o m
©️2021 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值