设计模式总结

设计模式是软件开发人员在软件开发过程中面临的一般问题的解决方案。这些解决方案是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的。
(本文主要是为了方便记忆,具体每个设计模式的内容会以链接的方式出现在对应的位置。)

七大原则

设计模式是依照七大原则设计出来的方案,掌握了七大原则,也就能在无形中使用设计模式。

  • 单一职责原则(SRP)
    单一职责原则,就一个类而言,应该仅有一个引起它变化的原因。
  • 开放-封闭原则
    软件实体(类、模块、函数等)应该可以扩展,但不可以修改。对于扩展是开放的,对于更改是封闭的。
  • 依赖倒转原则
    抽象不应该依赖细节,细节应该依赖于抽象。也就是说要针对接口编程,不要对实现编程。
  • 里氏代换原则
    一个软件实体如果使用的是一个父类的话,那么一定适用于其子类,而且它察觉不出父类对象和子类对象的区别。也就是子类型必须能够替换掉它们的父类型。
  • 迪米特法则
    迪米特法则,就是如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的,某一个方法的话,可以通过第三者转发这个调用。
  • 合成/聚合复用原则
    尽量使用合成/聚合,尽量不用使用类继承(这是一种强耦合)。优先使用对象的合成/聚合有助于保持每个类被封装,并被集中在单个任务上,这样类和类继承层次会保持比较小的规模,并且不大可能增长为不可控制的庞然大物。
  • 接口隔离原则
    接口隔离原则(Interface Segregation Principle) ,应当为客户端提供尽可能小的单独的接口,而不是提供大的总的接口。

23种设计模式

设计模式可以分为三类:创建型模式、结构型模式和行为型模式。

创建型模式

创建型模式是处理对象创建的设计模式,试图根据实际情况使用合适的方式创建对象。创建型模式有:工厂方法模式、抽象工厂模式、建造者模式、原型模式、单例模式。

1. 抽象工厂模式

抽象工厂模式是提供一个创建一系列相关或相互依赖对象的接口,而无需指定它们具体的类。


image

2. 建造者模式

建造者模式,就是将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。
建造者模式主要用于创建一些复杂的对象,这些对象内部构建间的构造顺序通常是稳定的,但对象内部的构建通常面临着复杂的变化。


image

3. 工厂方法模式

工厂方法模式定义了一个用于创建对象的接口,让子类决定实例化哪一个类。


image

4. 单例模式

单例模式,就说保证一个类仅有一个实例,并提供一个访问它的全局访问点。


image

5. 原型模式

原型模式,用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。


image

结构型模式

结构型模式主要是用于处理类或者对象的组合,它描述了如何使类或者对象更好的组合起来,是从程序的结构上来解决模块之间的耦合问题。结构型模式有:适配器模式、桥接模式、组合模式、装饰模式、外观模式、享元模式、代理模式。

1. 适配器模式

适配器模式,是将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。
系统的数据和行为都正确,但接口不符时,我们应该考虑用适配器。


image

2. 桥接模式

桥接模式,将抽象部分与它的实现部分分离,使它们都可以独立地变化。


image

3. 组合模式

组合模式,就是将对象组合成树形结构以表示‘部分-整体’的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。
需求中体现部分与整体层次的结构时,或希望用户可以忽略组合对象与单个对象的不同,统一地使用组合结构中的所有对象时,就应该考虑用组合模式了。


image

4. 装饰模式

装饰模式,动态地给一个对象添加一些额外的职责,就增加功能而言,装饰模式比生成子类更为灵活。
当系统需要增加新功能时,如果向旧的类中添加新的代码,通常这些代码是装饰了原有类的核心职责或主要行为,它们在主类中加入了新的字段、新的方法和新的逻辑,从而增加了主类的复杂度,而这些新加入的代码仅仅只是为了满足一些只在某种特定情况下才会执行的特殊行为的需求。这时装饰模式就是一个非常好的解决方案,它把每个要装饰的功能放在单独的类中,并让这个类包装它所要装饰的对象,因此,当需要执行特殊行为时,客户代码就可以在运行时根据需要有选择、按顺序地使用装饰功能包装对象了。


image

5. 外观模式

外观模式,为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

  • 在设计初期阶段,应该要有意识的将不同的两个层分离,在层与层之间建立外观Facade,这样可以为复杂的子系统提供一个简单的接口,使得耦合大大降低;
  • 在开发阶段,子系统往往因为不断的重构演化而变得越来越复杂,增加外观Facade可以提供一个简单的接口,减少它们之间的依赖;
  • 在维护一个遗留的大型系统是,可能这个系统已经非常难以维护和扩展了,但新需求的开发需要依赖这个系统,则可以为新系统开发一个外观Facade类,来提供设计粗糙或高复杂度的遗留代码的比较 清晰的简单接口,让新系统与Facade对象交互,Facade与遗留代码交互所有复杂的工作。


    image

6. 享元模式

享元模式,就是运用共享技术有效地支持大量细粒度的对象。

  • 如果一个应用程序使用了大量的对象,而这些对象造成了很大的存储开销时就应该考虑使用享元模式;
  • 对象的大多数状态可以是外部状态,如果删除对象的外部状态,那么可以用相对较少的共享对象取代很多组对象,此时可以考虑用享元模式。


    image

7. 代理模式

代理模式:为其他对象提供一种代理以控制对这个对象的访问。


image

行为型模式

行为型模式主要是用于描述类或者对象是怎样交互和怎样分配职责的。它涉及到算法和对象间的职责分配,不仅描述对象或者类的模式,还描述了他们之间的通信方式,它将你的注意力从控制流转移到了对象间的关系上来。行为型类模式采用继承机制在类间分派行为,而行为型对象模式使用对象复合而不是继承。行为型类模式有:职责链模式、命令模式、解释器模式、迭代器模式、中介者模式、备忘录模式、观察者模式、状态模式、策略模式、模板方法模式、访问者模式。

1. 职责链模式

职责链模式,就是使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系。将这个对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。


image

2. 命令模式

命令模式,是将一个请求封装为一个对象,从而使我们可以用不同的请求对客户进行参数化、对请求排队或记录请求日志,以及支持可撤销的操作。


image

3. 解释器模式

解释器模式,给定一个语言,定义它的文法的一种表示,并定义一个解释器,这个解释器使用该表示来解释语言中的句子。


image

4. 迭代器模式

迭代器模式,提供了一种方法顺序访问一个聚合对象中各个元素,而不暴露该对象的内部表示。

  • 当需要访问一个聚合对象,而且不管这些对象时什么都需要遍历的时候,就该考虑迭代器模式;
  • 需要对聚集有多种方式遍历时,可以考虑用迭代器模式。


    image

5. 中介者模式

中介者模式,就是用一个中介对象来封装一系列的对象交互。中介者使各对象不需要显示地相互引用,从而使其耦合松散,而且可以独立地改变它们之间的交互。
中介者模式一般用于一组对象以定义良好但是复杂的方式进行通信的场合,以及想定制一个分布在多个类中的行为,而又不想生成太多的子类的场合。


image

6. 备忘录模式

备忘录模式,在不破坏封装性的前提下,捕获一个对象的内部状态,并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。
Memento模式比较适用于功能比较复杂的,但需要维护或记录属性历史的类,或者需要保存的属性只是众多属性中的一小部分时,Originator可以根据保存的Memento信息还原到前一状态。


image

7. 观察者模式

观察者模式定义了一种一对多的依赖关系,让多个观察者对象同时监听某一个主题对象。这个主题对象在状态发生变化时,会通知所有观察者对象,使它们能够自动更新自己。

  • 当一个对象的改变需要同时改变其他对象,且不知道具体有多少对象有待改变时,应该考虑使用观察者模式;
  • 一个抽象模型有两个方面,其中一方面依赖于另一方面,这时可以用观察者模式将这两者封装在独立的对象中使它们各自独立地改变和复用。


    image

8. 状态模式

状态模型,就是当一个对象的内在状态改变时允许改变其行为,这个对象看起来像是改变了其类。
状态模式通过把各种状态转换转移逻辑分布到State的子类之间,来减少相互间的依赖。当一个对象的行为取决于它的状态,并且它必须在运行时根据状态改变它的行为时,就可以考虑使用状态模式了。


image

9. 策略模式

策略模式定义了算法家族,分别封装起来,让它们之间可以互相转换,此模式让算法的变化,不会影响到使用算法的用户。
模式策略是一种定义一系列算法的方法,从概念上看,所有这些算法完成的都是相同的工作,只是实现不同,它可以以相同的方式调用所有的算法,减少了各种算法类与使用算法类之间的耦合。实践中只要在分析过程出现需要在不同时间应用不同的业务规则,就可以考虑使用策略模式。


image

10. 模板方法模式

模版方法模式,就是定义一个操作中的算法的骨架,而将一些步骤延迟到子类中。模版方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。
当我们要完成在某一细节层次一致的一个过程或一系列步骤,但其个别步骤在更详细的层次上的实现可能不同时,通常考虑用模板方法模式来处理。


image

11. 访问者模式

访问者模式,表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。
访问者模式的目的是要把处理数据结构分离出来。如果系统可以按照算法和数据结构分开,且有比较稳定的数据结构,又有易于变化的算法的话,使用访问者模式就是比较合适的,因为访问者模式使用使得算法操作的增加变得容易。


image
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 204,590评论 6 478
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 86,808评论 2 381
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 151,151评论 0 337
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 54,779评论 1 277
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 63,773评论 5 367
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 48,656评论 1 281
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 38,022评论 3 398
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 36,678评论 0 258
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 41,038评论 1 299
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 35,659评论 2 321
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 37,756评论 1 330
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 33,411评论 4 321
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 39,005评论 3 307
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 29,973评论 0 19
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 31,203评论 1 260
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 45,053评论 2 350
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 42,495评论 2 343

推荐阅读更多精彩内容