设计模式------概述

设计模式----概述

---

一、面向对象设计原则

七种面向对象设计原则

• 单一职责原则

• 开放封闭原则

• 里氏代换原则

• 依赖倒转原则

• 接口隔离原则

• 合成复用原则

• 迪米特原则

二、设计模式（24种）

1.创建型模式（6种）

简单工厂模式

简单工厂模式(Simple Factory)定义一个工厂类，它可以根据参数的不同返回不同类的实例，被创建的实例通常都具有共同的父类。因为在简单工厂模式中用于创建实例的方法是静态(static)方法，因此简单工厂模式又被称为静态工厂方法(Static Factory Method)模式，它属于类创建型模式。

本质：选择实现

UML

优点：
        工厂类含有必要的判断逻辑，根据客户端的选择条件动态实例化相关类，对于客户端来说，去除了与具体产品的依赖


缺点：
        在某种程度上违背了开放–封闭原则
        对工厂类过于依赖

工厂方法模式

工厂方法模式(Factory Method Pattern)：定义一个用于创建对象的接口，让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。工厂方法模式又简称为工厂模式(Factory Pattern)，又可称作虚拟构造器模式(Virtual Constructor Pattern)或多态工厂模式(Polymorphic Factory Pattern)。工厂方法模式是一种类创建型模式。

本质：延迟到子类来选择实现

UML

优点：
        当系统扩展需要添加新产品对象时，仅仅需要添加一个具体对象以及一个具体工厂对象，原有工厂对象不需要进行任何修改，也不需要（尽量小的）修改客户端，较好的符合了”开放-封闭“原则。而简单工厂模式在添加新产品对象后不得不修改工厂方法，扩展性不好。


缺点：
        具体产品对象与工厂方法的耦合性：工厂方法是要创建产品对象的，也就是需要选择具体的产品对象，并创建他们的实例。因此具体产品对象与工厂方法是耦合的

抽象工厂模式

抽象工厂模式(Abstract Factory Pattern)：提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。抽象工厂模式又称为Kit模式，它是一种对象创建型模式。

本质：选择产品族的实现

UML

优点：
        分离接口和实现
        使得切换产品族变得容易


缺点：
        不太容易扩展新的产品
        容易造成类层次复杂

单例模式

单例模式(Singleton Pattern)：确保某一个类只有一个实例，而且自行实例化并向整个系统提供这个实例，这个类称为单例类，它提供全局访问的方法。单例模式是一种对象创建型模式。

本质：控制实例数目

UML

原型模式

原型模式(Prototype Pattern)：使用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。原型模式是一种对象创建型模式。

本质：克隆生成对象

UML

优点：
        允许动态添加或减少产品类。由与创建产品类实例的方法时产品类内部具有的，因此增加新产品对整个结构没有影响
        提供简化的创建结构。工厂方法模式常常需要有一个与产品类等级结构相同的等级结构，而Prototype模式就不需要这样。


缺点：
        最主要的缺点是每个原型的子类都必须实现clone的操作，尤其在包含引用类型对象时，clone方法会比较麻烦，必须要能够递归地让所有的相关对象都要正确地实现克隆。

建造者模式

建造者模式(Builder Pattern)：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。建造者模式是一种对象创建型模式。

本质：分离整体构建算法和部件构造

UML

优点：
        建造者模式的使用使得产品的内部表象可以独立的变化。使用建造者模式可以使客户端不必知道产品内部组成的细节。
        每一个Builder 都相对独立，而与其它的Builder 无关。
        模式所建造的最终产品更易于控制。

2.结构型模式（7种）

适配器模式

适配器模式(Adapter Pattern)：将一个接口转换成客户希望的另一个接口，使接口不兼容的那些类可以一起工作，其别名为包装器(Wrapper)。适配器模式既可以作为类结构型模式，也可以作为对象结构型模式。

本质：转换匹配，复用功能

UML

优点：
        更好的复用性
        更好的可扩展性：在实现适配器功能的时候，可以调用自己开发的功能，从而自然地扩展系统的功能


缺点：
        过多地使用适配器，会让系统非常凌乱，不容易整体进行把握。

桥接模式

桥接模式(Bridge Pattern)：将抽象部分与它的实现部分分离，使它们都可以独立地变化。它是一种对象结构型模式，又称为柄体(Handle and Body)模式或接口(Interface)模式。

本质：分离抽象和实现

UML

两个等级结构
        由抽象化角色和修正抽象化角色组成的抽象化等级结构
        由实现化角色和两个具体实现化角色所组成的实现化等级结构

组合模式

组合模式(Composite Pattern)：组合多个对象形成树形结构以表示具有“整体—部分”关系的层次结构。组合模式对单个对象（即叶子对象）和组合对象（即容器对象）的使用具有一致性，组合模式又可以称为“整体—部分”(Part-Whole)模式，它是一种对象结构型模式。

本质：统一叶子对象和组合对象

UML

优点：
        定义了包含基本对象和组合对象的类层次结构:基本对象可以组合成组合对象，组合对象又能组合成更复杂的组合对象，可以不断地递归组合下去,从而构成一个统一的组合对象的类层次结构
        统一了组合对象和叶子对象
        简化了客户端调用:不用区分组合对象和叶子对象
        更容易扩展:由于客户端是统一的面对Component来操作，因此,新定义的Composite或leaf子类能够很容易的与已有的结构一起工作，而不需改变客户端


缺点：
        很难限制组合中的组件类型:这是容易添加新的组件带来的问题，在需要检测组件类型的时候，使得我们不能依靠编译期的类型约束来完成，必须在运行期间动态检测

装饰模式

装饰模式(Decorator Pattern)：动态地给一个对象增加一些额外的职责，就增加对象功能来说，装饰模式比生成子类实现更为灵活。装饰模式是一种对象结构型模式。

本质：动态组合

UML

优点：
        装饰模式与继承关系的目的都是要扩展对象的功能，但是装饰模式可以提供比继承更多的灵活性。
        通过使用不同的具体装饰类以及这些装饰类的排列组合，设计师可以创造出很多不同行为的组合


缺点：
        会产生很多细粒度对象。

外观模式

外观模式：为子系统中的一组接口提供一个统一的入口。外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。

本质：封装交互，简化调用

UML

优点：
        屏蔽了外部客户端和系统内部模块的交互
        Facade的功能可以被多个客户端调用，可以实现复用（功能的共享）
        对使用Facade的人员来说，Facade大大的节省了他们的学习成本。

缺点：
        不符合开闭原则。

享元模式

享元模式(Flyweight Pattern)：运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，它是一种对象结构型模式。

本质：分离与共享

UML

优点：
        大幅度地降低内存中对象的数量，节省内存空间

缺点：
        享元模式使得系统更加复杂。为了使对象可以共享，需要将一些状态外部化，这使得程序的逻辑复杂化。
        享元模式将向原对象的状态外部化，而读取外部状态使得运行时间变长。

代理模式

代理模式：给某一个对象提供一个代理或占位符，并由代理对象来控制对原对象的访问。

本质：控制对象访问

UML

分类：
(1)远程代理:为位于两个不同地址空间对象的访问提供了一种实现机制，可以将一些消耗资源较多的对象和操作移至性能更好的计算机上，提高系统的整体运行效率。
(2) 虚拟代理:通过一个消耗资源较少的对象来代表一个消耗资源较多的对象，可以在一定程度上节省系统的运行开销。
(3) 缓冲代理:为某一个操作的结果提供临时的缓存存储空间，以便在后续使用中能够共享这些结果，优化系统性能，缩短执行时间。
(4) 保护代理:可以控制对一个对象的访问权限，为不同用户提供不同级别的使用权限。

优点：
         能够协调调用者和被调用者，在一定程度上降低了系统的耦合度。
        客户端可以针对抽象主题角色进行编程，增加和更换代理类无须修改源代码，符合开闭原则，系统具有较好的灵活性和可扩展性。

缺点：
        由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。
        实现代理模式需要额外的工作，有些代理模式的实现非常复杂。

3.行为型模式（11种）

职责链模式

职责链模式(Chain of Responsibility Pattern)：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式是一种对象行为型模式。

本质：分离职责，动态组合

UML

优点：
         请求者和接收者松散耦合
        动态组合职责

缺点：
        产生很多细粒度对象
        不一定能被处理：需要提供默认处理

命令模式

命令模式(Command Pattern)：将一个请求封装为一个对象，从而让我们可用不同的请求对客户进行参数化；对请求排队或者记录请求日志，以及支持可撤销的操作。命令模式是一种对象行为型模式，其别名为动作(Action)模式或事务(Transaction)模式。

本质：封装请求

UML

优点：
命令允许请求的一方和接收请求的一方能够独立演化。
        1、命令模式使新的命令很容易地被加入到系统里。
        2、允许接收请求的一方决定是否要否决(Veto) 请求。
        3、能较容易地设计一个命令队列。
        4、可以容易地实现对请求的Undo和Redo。
        5、在需要的情况下，可以较容易地将命令记入日志。
        6、命令模式把请求一个 操作的对象与知道怎么执行一个操作的对象分割开。
        7、命令类与其他任何别的类-样，可以修改和推广。

解释器模式

解释器模式(Interpreter Pattern)：定义一个语言的文法，并且建立一个解释器来解释该语言中的句子，这里的“语言”是指使用规定格式和语法的代码。解释器模式是一种类行为型模式。

迭代器模式

迭代器模式(Iterator Pattern)：提供一种方法来访问聚合对象，而不用暴露这个对象的内部表示，其别名为游标(Cursor)。迭代器模式是一种对象行为型模式。

中介者模式

中介者模式(Mediator Pattern)：用一个中介对象（中介者）来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互。中介者模式又称为调停者模式，它是一种对象行为型模式。

本质：封装交互

UML

优点：
         Mediator模式是一种很有用并且很常用的模式，它通过将对象间的通信封装到一个类中，将多对多的通信转化为一对多的通信，降低了系统的复杂性。
        Mediator还获得系统解耦的特性，通过Mediator,各个Colleague就不必维护各自通信的对象和通信协议，降低了系统的耦合性，Mediator和各个Colleague就可以相互独立地修改了。
        Mediator模式还有一个很显著的特点就是将控制集中,集中的优点就是便于管理，也正符合了OO设计中的每个类的职责要单一和集中的原则。

缺点：
        由于控制的集中化，于是把交互复杂性变为了中介者的复杂性，这就使得中介者会变得比任何一个ConcreteColleague都复杂。

备忘录模式

备忘录模式(Memento Pattern)：在不破坏封装的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，这样可以在以后将对象恢复到原先保存的状态。它是一种对象行为型模式，其别名为Token。

本质：保护和恢复内部状态

UML

优点：
         有时一些发起人对象的内部信息必须保存在发起人对象以外的地方，但是必须要由发起人对象自己读取。这时，使用备忘录模式可以把复杂的发起人内部信息对其他的对象屏蔽起来，从而可以恰当地保持封装的边界。
        本模式简化了发起人类。发起人不再需要管理和保存其内部状态的一个个版本，客户端可以自行管理他们所需要的这些状态的版本。
        当发起人角色的状态改变的时候，有可能这个状态无效，这时候就可以使用暂时存储起来的备忘录将状态复原。

缺点：
        如果发起人角色的状态需要完整地存储到备忘录对象中，那么在资源消耗上面备忘录对象会很大。
        当管理者角色将一个备忘录存储起来的时候,管理者可能并不知道这个状态会占用多大的存储空间，从而无法提醒用户一个操作是否很大。

观察者模式

观察者模式(Observer Pattern)：定义对象之间的一种一对多依赖关系，使得每当一个对象状态发生改变时，其相关依赖对象皆得到通知并被自动更新。观察者模式的别名包括发布-订阅（Publish/Subscribe）模式、模型-视图（Model/View）模式、源-监听器（Source/Listener）模式或从属者（Dependents）模式。观察者模式是一种对象行为型模式。

本质：触发联动

UML

优点：
         观察者模式实现了观察者和目标之间的抽象耦合。
        观察者模式实现了动态联动
        观察者模式支持广播通信。被观察者会向所有登记过的观察者发出通知。

缺点：
        可能会引起无谓的操作。
采用广播的方式，不管观察者需不需要，每个观察者都会被调用update方法。

状态模式

状态模式(State Pattern)：允许一个对象在其内部状态改变时改变它的行为，对象看起来似乎修改了它的类。其别名为状态对象(Objects for States)，状态模式是一种对象行为型模式。

本质：根据状态来分离和选择行为
           状态模式是状态驱动，由上下文负责。

UML

优点：
        将与特定状态相关的行为局部化，并且将不同状态的行为分割开来。
        消除庞大的条件分支语句，把各种状态转移逻辑分布到State的子类之间，减少了相互间的依赖。
        显式化进行状态转换:为不同的状态引入独立的对象，使得状态的转换变得更如明确。而且状态对象可以保证上下文不会发生内部状态不一致的状况，因为上下文中只有一个变量来记录状态对象，只要为这一个变量赋值就可以了。

缺点：
        逻辑分散化，状态逻辑分布到了很多的State的子类中，很难看到整个的状态逻辑图，这也带来了代码的维护问题。

策略模式

策略模式(Strategy Pattern)：定义一系列算法类，将每一个算法封装起来，并让它们可以相互替换，策略模式让算法独立于使用它的客户而变化，也称为政策模式(Policy)。策略模式是一种对象行为型模式。

本质：分离算法，选择实现

UML

优点：
        策略模式可以避免让客户端涉及到不必要接触到的复杂的和只与算法有关的数据。
        避免使用难以维护的多重条件选择语句。
        更好的扩展。

缺点：
        把分支判断又放回到客户端，要改变需求算法时，还是要去更改客户端的程序。
        客户端必须知道所有的策略类，并自行决定使用哪一个策略类。这就意味着客户端必须理解这些算法的区别，以便适时选择恰当的算法类。
        增加了对象的数目。
        只适合扁平的算法结构。

模板方法模式

模板方法模式：定义一个操作中算法的框架，而将一些步骤延迟到子类中。模板方法模式使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。

本质：固定算法骨架

UML

优点：
        实现代码复用

缺点：
        算法骨架不容易升级（模板和子类是非常耦合的，如要对模板中的算法骨架进行变更，会影响子类变化）

访问者模式

访问者模式(Visitor Pattern):提供一个作用于某对象结构中的各元素的操作表示，它使我们可以在不改变各元素的类的前提下定义作用于这些元素的新操作。访问者模式是一种对象行为型模式。

本质：预留通路，回调实现

UML

双重分派：
        数据结构的每一个节点都可以接受一个访问者的调用，此节点向访问者对象穿入节点对象，而访问者对象则反过来执行节点对象的操作。

优点：
        访问者模式使得增加新的操作变得很容易。增加新的操作就意味着增加一个新的访问者类。
        访问者模式将有关的行为集中到一个访问者对象中，而不是分散到一个个的节点类中。

缺点：
        增加新的节点变得很困难。每增加一个新的节点都意味着要在抽象访问者角色中增加一个新的抽象操作，并在每一个具体访问者类中增加相应地具体操作。
        破坏封装。访问者模式要求访问者对象访问并调用每一个节点对象的操作，这隐含了一个对所有几点对象的要求：特曼必须暴露一些自己的操作和内部状态。