各类设计模式的简单介绍

设计模式的六大原则

• 单一职责原则
• 里氏替换原则
• 依赖倒置原则
• 接口隔离原则
• 迪米特原则
• 开闭原则

设计模式的分类

建立型模式

建立型模式：对对象实例化的抽象，经过采用抽象类所定义的接口，封装了系统中对象如何建立，组合等信息。包括如下几种设计模式

抽象工厂模式

优势

• 分离了具体类
• 更容易在产品系列中进行转换
• 提升了产品间一致性

缺点

• 难以支持新的产品等级结构
• 支持新的产品等级结构就要扩展原来的抽象工厂接口

适用场景

• 系统独立于产品的建立，组成以及表示
• 系统配置成具备多个产品的系列
• 当要强调一系列相关的产品对象的设计便于进行联合使用时
• 当提供一个产品类库，而只想显示它们的接口而不是实现时

应用举例

在不少软件系统中须要更换界面主题，要求界面中的按钮，文本框，背景色等一块儿发生改变时可使用抽象工厂模式进行设计

构建器模式

优势

• 产品的内部表象能够独立变化
• 将构建代码与表示代码相分离，可使客户端没必要知道产品内部组成的细节

缺点

• 构建器模式建立的产品通常具备较多的共同点，其组成部分类似，若是产品之间差别性很大。则不适合使用构建器模式
• 若是产品的内部变化复杂，可能会致使须要定义不少具体建造者类来实现这种变化，致使系统变得很庞大

适用场景

建立复杂对象的算法独立于组成对象的部分以及这些部分的集合方式 构造过程必须容许已构建对象有不一样表示

应用举例

在不少游戏软件中，地图包括天空，地面背景等组成部分，人物角色包括人体，服装，装备等组成部分，可使用建造者模式对其进行设计，经过不一样的具体建造者建立不一样类型的地图或人物

工厂方法模式

定义一个用于建立对象(产品)的接口，由子类决定实例化那个类的对象（ 产品）

优势

• 没有了将应用程序绑定到代码中的要求，代码只处理接口，所以可使用任何实现了接口的类
• 容许子类提供对象的扩展版本
• 符合迪米特法则，依赖倒置原则，里氏替换原则

缺点

• 须要Creator和相应的子类做为工厂方法的载体，若是应用模型确实须要creator的子类存在，则很好，不然须要增长一个类层次

适用场景

• 当一个类不知道他所建立的产品的具体是那个子类时
• 当建立对象的过程但愿延缓到子类中进行时
• 类但愿子类指定他要建立的对象

应用举例

Windows的COM组件与MFC

原型模式

指定建立对象的种类，而且经过拷贝这些原型建立新的对象，以一个已有的对象做为原型，经过他来建立新对象

优势

• 能够在容许时添加或删除产品
• 原型模式提供简化的建立结构
• 具备给一个应用软件加载新功能的能力
• 产品类不须要非得由任何实现肯定的等级结构

缺点

每个类必须配备一个克隆方法

适用场景

• 在运行时，指定须要实例化的类，例如动态载入，避免构建与产品的类层次结构类似的共产类层次结构
• 当类的实例是仅有的一些不一样状态组合

单例模式

一个类只有一个实例

优势

• 对单个实例的受控制访问
• 名称空间减小
• 容许改进操做和表示
• 容许可变数目的实例
• 比类操做更灵活

缺点

单例类的扩展有很大困难，且职责太重，这在必定程度上违背了单一职责原则

适用场景

只有一个类实例

应用举例

逐渐生成器

结构型模式

主要用于如何组合已有的类和对象以得到更大的结构，它采用继承机制组合接口来实现，以提供 统一的外部试图或新的功能

适配器模式

将一个类的接口转换成客户但愿的另一个接口，Adapter模式使得本来的接口不兼容而不能一块儿工做的那些类能够一块儿工做

优势

• 容许两个或多个不兼容的对象进行交互和通讯
• 提升已有功能的重复适用
• 增长了类的透明度
• 灵活性

缺点

过多的适用适配器会让系统很是凌乱，不易总体进行把握

适用场景

• 要使用已有的类，而该类接口与所需的接口并不匹配
• 要建立可重复使用的类，该类能够与不相干或未知类进行协助，即类之间不须要兼容接口
• 要在一个不一样于已知接口的接口环境重使用对象
• 必需要进行多个源之间的接口转换的时候

应用举例

在.Net重有一个类库已经实现的，很是重要的适配器——Data Adapter

桥接模式

将一个辅助的组件分红两个独立的但又相关的继承层次结构

优势

• 能够将接口与是实现相分离
• 提升可扩展性
• 对客户端隐藏了实现细节

缺点

• 增长了系统的理解和设计难度
• 要求正确的识别出系统重两个独立变化的维度，所以其使用范围有必定的局限性

适用场景

• 想避免在抽象及其实现之间存在永久的绑定
• 抽象及其实现可使用子类进行扩展
• 抽象的实现被改动应该对客户端没有影响

组合模式

将对象组合成树型结构以表示“部分-总体”的层次结构

优势

• 清楚的定义分层次的复杂对象，表示对象的所有或部分层次
• 使得增长新构件 更容易了了
• 提升告终构的灵活性和可管理的接口

缺点

使设计变得更加抽象。若是对象的业务规则很复杂，则实现组合模式具备很大的挑战性，并且不是全部的方法都与叶子对象子类有关联

适用场景

• 想表示对象的部分--总体层次结构
• 但愿用户忽略组合对象与单个对象的不一样，用户将统一的使用组合结构重的全部对象
• 结构能够具备任何级别的复杂性，并且是动态的

应用举例

部分、总体场景如树型菜单，文件，文件夹的管理

装饰模式

动态的给对象添加一些额外的责任，就增长功能来讲，装饰比生成子类更为灵活

优势

• 比静态继承具备更大的灵活性
• 简化代码
• 改进对象的扩展性，用户能够经过编写新的类来作出改变
• 装饰类和被装饰类能够独立发展，不会相互耦合

缺点

多层装饰比较复杂

适用场景

• 想要在单个对象动态而且透明的添加责任，而这样不会影响其余对象
• 想要在之后可能要修改的对象重添加责任
• 当没法经过静态子类化实现扩展时

外观模式

为子系统重的一组接口提供一个统一的接口，外观模式经过一个高层接口隔离了外部系统与子系统间复杂的交互过程，使得复杂系统的子系统更容易使用

优势

• 在不减小系统所提供的选项的状况下，为复杂系统提供了简单的接口
• 客户端屏蔽了子系统组件
• 提升了子系统和其客户端之间的弱耦合度
• 将客户端请求转发后可以处理这些请求的子系统

缺点

• 不能很好的限制客户使用子系统类，若是对客户访问子系统作太多的限制，则减小了可变性和灵活性
• 在不引入抽象外观类的状况下，增长新的子系统可能须要修改外观类或客户端的源代码，违背了开闭原则

适用场景

• 为一个复杂子系统提供一个简单接口时
• 客户程序与抽象类的实现之间存在着很大的依赖性
• 构建一个层次结构的子系统时，适用Facade模式定义子系统中每层的入口点，若是子系统之间是相互依赖的，你可让他们仅经过Facade进行通讯，从而简化了他们之间的依赖关系

享元模式

经过共享对象减小系统中低等级的，详细的对象数目

优势

• 减小了要处理的对象数目
• 若是对象可以持续，能够减小内存和存储设备

缺点

• 使得应用程序在某种程度上来讲更加复杂化了
• 为了使对象能够共享，享元模式须要将享元对象的状态外部化，而读取外部状态使得运行时间变长

适用场景

• 应用程序使用大量的对象
• 因为对象数目巨大，致使很高的存储开销
• 应用程序不依赖于对象的身份

代理模式

为控制初始对象的访问，提供了一个代理或者占位符对象

优势

• 远程代理能够隐藏对象位于不一样的地址空间的事实
• 虚拟代理能够执行优化操做

缺点

• 请求的处理速度变慢
• 实现代理模式须要额外的工做，从而增长了系统实现的复杂度

适用场景

• 当须要为了一个对象在不一样的地址空间提供局部的表明时
• 当须要建立开销很是大的对象时

应用举例

防火墙代理---保护目标不让恶意用户靠近

行为型模型

从大量的实际行动中归纳出来做为行为的理论抽象、基本框架和标准，该类模式主要用于对象之间的职责及其提供的服务的分配，他不只描述对象或类的模式，还描述它们之间的通讯模式

责任链模式

在系统中创建一个链，消息能够首先接收到他的级别被处理，或者定位到能够处理他的对象

优势

• 下降耦合度
• 增长向对象指定责任的灵活性

适用场景

• 多个对象能够处理一个请求，而其处理器倒是未知的
• 能够动态指定可以处理请求的对象集

命令模式

在对象中封装请求，保存命令并传递给方法以及任何其余对象同样返回该命令

优势

• 添加新命令不用修改已有类
• 将操做对象与知道如何完成操做的对象相分离

适用场景

• 想要经过要执行的动做来参数化对象
• 在不一样的时间指定、排序以及执行请求

解释器模式

解释定义其语法表示的语言

优势

• 容易修改并扩展语法
• 容易实现语法

适用场景

• 语言的语法比较简单
• 效率并非最主要的问题

迭代器模式

提供一种方法顺序的访问一个聚合对象中的各个元素，而又不暴露改对象的内部表示

优势

• 支持集合的不一样遍历
• 简化集合接口

适用场景

• 在不开放集合内部对象表示的前提下访问集合对象内容
• 支持记号个对象的多重遍历
• 为遍历集合中的不一样结构提供了统一的接口

备忘录模式

保持对象状态的“快照”，在不向外界公开其内容的状况下返回到它的最初状态

优势

• 保持封装完整
• 简化了返回到初始状态所需的操做

适用场景

• 必须保存对象的快照
• 适用直接接口来得到状态有可能会公开对象的实现细节，从而破坏对象的封装性

观察者模式

为组件向相关接收方广播消息提供了灵活的方法

优势

• 抽象了主体与Observer 之间的耦合关系
• 支持广播方式的通讯

####适用场景

• 对一个对象的修改涉及其余对象的修改，而不知道有多少对象须要修改
• 对象应该能在不设置对象标识的状况下通知其余对象

状态模式

容许对象在内部状态变化时变动其行为，而且修改其类

优势

• 定位指定状态的行为，并根据不一样的状态来划分行为

适用场景

• 对象行为依赖于其状态，且对象必须在运行时根据其状态修改行为
• 操做具备大量以及多部份组成的取决于对象状态的条件语句

策略模式

定义了一组用来表示可能行为集合的类

优势

• 另外一种子类化方法
• 在类自身中定义行为，减小条件语句
• 更容易扩展模型

适用场景

• 许多相关类只是在行文方面有所区别
• 须要算法的不一样变体
• 算法使用客户端未知的数据

模板方法模式

提供了在不重写方法的前提下容许子类重载部分方法的方法

优势

• 代码使用

适用场景

• 想要一次实现算法的不变部分，适用子类实现算法的可变行为
• 子类间通用行为须要分解，定位到通用类，能够避免代码重复问题

访问者模式

提供了一种方便的，可维护的方法来表示在对象结构元素上进行的操做。改模式容许在不改变操做元素的类的前提下定义一个新操做

优势

• 容易添加新操做
• 集中相关操做而且排除不相关操做

适用场景

• 定义对象结构的类不多被修改，但想要在此结构上定义新的操做
• 对象结构包含许多具备不一样接口的对象类，而且想要对这些依赖于具体的类的对象进行操做

中介者模式

经过引入一个可以管理对象间消息分布的对象，简化系统中对象的通讯

优势

• 取出对象间的影响
• 简化对象间的协议
• 集中化控制

适用场景

• 对象集合须要一个定义但复杂的方式进行通讯
• 想要在不使用子类的状况下自定义分布在几个对象间的行为

本文由博客一文多发平台 OpenWrite 发布！