设计模式

帮助开发人员更有效地设计可重用、可维护和可扩展的软件系统。完善的列举了各类设计模式以及设计原则，并辅以详细的案例帮你更好的理解设计模式的使用场景。

设计模式

• 设计模式的目的：因为业务的千遍万化 所以在熟悉业务的基础上 评估会变化的点，因其变化的不通看似像似的场景要使用的 设计模式也是不通的 为以后软件功能的增加留好扩展点，让软件具有更好的易读行，与易扩展性
• 7大原则
  • 单一职责原则
    • 一个类只负责一项职责 好处： 1) 降低类的复杂度，一个类只负责一项职责。 2) 提高类的可读性，可维护性 3)降低变更引起的风险 4)通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单的时候可以在类中违反单一职责原则，在方法级别保持单一职责原则
  • 接口隔离原则
    • 客户端不应该依赖他不需要的接口，一个类对另一个类的依赖应该建立在最小的接口上
  • 依赖倒置原则
    • 1)高层模块不应该依赖低层模块，二者都应该依赖其抽象 2)抽象不应该依赖细节，细节应该依赖抽象 3)依赖倒转(倒置)的中心思想是面向接口编程 4)依赖倒转原则是基于这样的设计理念:相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构比以细节为基础的架构要稳定的多。在java中，抽象指的是接口或抽象类，细节犹是具体的实现类 5)使用接 口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
  • 里氏替换原则
    • 1.所有引用基类的地方必须能透明的使用其子类对象 2.在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法 3.里氏替 换原则告诉我们，继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题。 什么是继承： 1) 继承包含这样一 层含义:父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵循这些契约，但是如果子类对这些已经实现的方法任意修改，就会对整个继承体系造成破坏。 2)继承在给程序设计带来便利的同时，也带来了弊端。比如使用继承会给程序带来侵入性，程序的可移植性降低，增加对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能产生故障
  • 迪米特法则
    • 迪米特法则(Demeter Principle)又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除了提供的public方法，不对外泄露任何信息 目的：降低类之间的耦合
  • 开闭原则
    • 1) 一 个软件实体如类，模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方)。用抽象构建框架，用实现扩展细节。 2)当 软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化。 3)编程中遵循其它原则，以及使用设计模式的目的就是遵循开闭原则。
  • 组合/聚合复用原则
    • 1) 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混在一 起。 2)针对 接口编程，而不是针对实现编程。 3)为了交互对象之间的松耦合设计而努力
• UML类图
  • 基本介绍
    • 1) UML- - Unified modeling language UML (统一建模语言)， 是一种用于软件系统分析和设计的语言工具，它用于帮助软件开发人员进行思考和记录思路的结果 2) UML 本身是一-套符号的规定，就像数学符号和化学符号-样，这些符号用于描述软件模型中的各个元素和他们之间的关系，比如类、接口、实现、泛化、依赖、组合、聚合等，如右图: 
  • UML图
    • 用例图
    • 静态结构图
      • 类图
        • 描述类与类之间的关系，UML图里面最核心的内容
        • 依赖
          • 只要是在类中用到了对方，那么他们之间就存在依赖关系。 连接线： 
        • 泛化（继承）
          • 泛化关系实际上就是继承关系，他是依赖关系的特例 连接线： 
        • 实现
          • 实现关系实际上就是A类实现B接口，他是依赖关系的特例 连接线： 
        • 关联
          • 实际上是类与类之间的联系，是依赖关系的特例
        • 聚合
          • 聚合关系(Aggregation) 表示的是整体和部分的关系，整体与部分可以分开。聚合关系是关联关系的特例，所以他具有关联的导航性与多重性。 如:一台电脑由键盘(keyboard)、显示器(monitor)，鼠标等组成;组成电脑的各个配件是可以从电脑上分离出来的，使用带空心菱形的实线来表示:
        • 组合
          • 组合关系:也是整体与部分的关系，但是整体与部分不可以分开。 再看一个案例:在程序中我们定义实体: Person与IDCard、Head,那么Head和Person 就是组合，IDCard和Person就是聚合。
      • 对象图
      • 包图
      • 组件图
      • 部署图
    • 动态行为图
      • 交互图
        • 时序图
        • 协作图
      • 状态图
      • 活动图
• 结构型
  • 本质
    • 处理类或者对象的组合
  • 两种类型
    • 类结构类型
    • 对象结构类型
  • 7种模式
    • 适配器模式 Adapter
      • 适配器模式（Adapter Pattern）是作为两个不兼容的接口之间的桥梁。这种类型的设计模式属于结构型模式，它结合了两个独立接口的功能。 这种模式涉及到一个单一的类，该类负责加入独立的或不兼容的接口功能。举个真实的例子，读卡器是作为内存卡和笔记本之间的适配器。您将内存卡插入读卡器，再将读卡器插入笔记本，这样就可以通过笔记本来读取内存卡。
      • 介绍
        • 意图：将一个类的接口转换成客户希望的另外一个接口。适配器模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。 主要解决：主要解决在软件系统中，常常要将一些"现存的对象"放到新的环境中，而新环境要求的接口是现对象不能满足的。 何时使用： 1、系统需要使用现有的类，而此类的接口不符合系统的需要。 2、想要建立一个可以重复使用的类，用于与一些彼此之间没有太大关联的一些类，包括一些可能在将来引进的类一起工作，这些源类不一定有一致的接口。 3、通过接口转换，将一个类插入另一个类系中。（比如老虎和飞禽，现在多了一个飞虎，在不增加实体的需求下，增加一个适配器，在里面包容一个虎对象，实现飞的接口。） 如何解决：继承或依赖（推荐）。 关键代码：适配器继承或依赖已有的对象，实现想要的目标接口。 应用实例： 1、美国电器 110V，中国 220V，就要有一个适配器将 110V 转化为 220V。 2、JAVA JDK 1.1 提供了 Enumeration 接口，而在 1.2 中提供了 Iterator 接口，想要使用 1.2 的 JDK，则要将以前系统的 Enumeration 接口转化为 Iterator 接口，这时就需要适配器模式。 3、在 LINUX 上运行 WINDOWS 程序。 4、JAVA 中的 jdbc。 优点： 1、可以让任何两个没有关联的类一起运行。 2、提高了类的复用。 3、增加了类的透明度。 4、灵活性好。 缺点： 1、过多地使用适配器，会让系统非常零乱，不易整体进行把握。比如，明明看到调用的是 A 接口，其实内部被适配成了 B 接口的实现，一个系统如果太多出现这种情况，无异于一场灾难。因此如果不是很有必要，可以不使用适配器，而是直接对系统进行重构。 2.由于 JAVA 至多继承一个类，所以至多只能适配一个适配者类，而且目标类必须是抽象类。 使用场景：有动机地修改一个正常运行的系统的接口，这时应该考虑使用适配器模式。 注意事项：适配器不是在详细设计时添加的，而是解决正在服役的项目的问题。
      • 类适配器（继承）
      • 对象适配器（组合）
        • 合成复用原则的优化
      • 接口适配器
        • 核心思路:当不需要全部实现接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中每个方法提供一个默认实现 (空方法)，那么该抽象类的子类可有选择地覆盖父类的某些方法来实现需求（迪米特法则）
      • 例子
    • 桥接模式 Bridge
      • 将实现与抽象放到不同的层次里，使两个层次可以独立改变 Bridge模式基于类的最小设计原则，通过使用封装、聚合及继承等行为让不同的类承担不同的职责。它的主要特点是把抽象(Abstraction)与行为实现(Implementation)分离开来,从而可以保持各部分的独立性以及应对他们的功能扩展
      • 原理图
        •  1) Client类:桥接模式的调用者 2)抽象类(Abstraction) :维护了Implementor 1即它的实现类ConcretelmplementorA..二者是聚合关系, Abstraction充当桥接类 3) RefinedAbstraction: 是Abstraction 抽象类的子类 4) Implementor: 行为实现类的接口 5) ConcretelmplementorA/B :行为的具体实现类 6)从UML图:这里的抽象类和接口是聚合的关系，其实调用和被调用关系
    • 外观模式 Facade
      • 外观模式（Facade Pattern）隐藏系统的复杂性，并向客户端提供了一个客户端可以访问系统的接口。这种类型的设计模式属于结构型模式，它向现有的系统添加一个接口，来隐藏系统的复杂性。 这种模式涉及到一个单一的类，该类提供了客户端请求的简化方法和对现有系统类方法的委托调用
      • 介绍
        • 意图：为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。 主要解决：降低访问复杂系统的内部子系统时的复杂度，简化客户端之间的接口。 何时使用： 1、客户端不需要知道系统内部的复杂联系，整个系统只需提供一个"接待员"即可。 2、定义系统的入口。 如何解决：客户端不与系统耦合，外观类与系统耦合。 关键代码：在客户端和复杂系统之间再加一层，这一层将调用顺序、依赖关系等处理好。 应用实例： 1、去医院看病，可能要去挂号、门诊、划价、取药，让患者或患者家属觉得很复杂，如果有提供接待人员，只让接待人员来处理，就很方便。 2、JAVA 的三层开发模式。 优点： 1、减少系统相互依赖。 2、提高灵活性。 3、提高了安全性。 缺点：不符合开闭原则，如果要改东西很麻烦，继承重写都不合适。 使用场景： 1、为复杂的模块或子系统提供外界访问的模块。 2、子系统相对独立。 3、预防低水平人员带来的风险。 注意事项：在层次化结构中，可以使用外观模式定义系统中每一层的入口。
    • 组合模式 Composite
      • 组合模式（Composite Pattern），又叫部分整体模式，是用于把一组相似的对象当作一个单一的对象。组合模式依据树形结构来组合对象，用来表示部分以及整体层次。这种类型的设计模式属于结构型模式，它创建了对象组的树形结构。 这种模式创建了一个包含自己对象组的类。该类提供了修改相同对象组的方式。 我们通过下面的实例来演示组合模式的用法。实例演示了一个组织中员工的层次结构。
      • 介绍
        • 意图：将对象组合成树形结构以表示"部分-整体"的层次结构。组合模式使得用户对单个对象和组合对象的使用具有一致性。 主要解决：它在我们树型结构的问题中，模糊了简单元素和复杂元素的概念，客户程序可以像处理简单元素一样来处理复杂元素，从而使得客户程序与复杂元素的内部结构解耦。 何时使用： 1、您想表示对象的部分-整体层次结构（树形结构）。 2、您希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。 如何解决：树枝和叶子实现统一接口，树枝内部组合该接口。 关键代码：树枝内部组合该接口，并且含有内部属性 List，里面放 Component。 应用实例： 1、算术表达式包括操作数、操作符和另一个操作数，其中，另一个操作数也可以是操作数、操作符和另一个操作数。 2、在 JAVA AWT 和 SWING 中，对于 Button 和 Checkbox 是树叶，Container 是树枝。 优点： 1、高层模块调用简单。 2、节点自由增加。 缺点：在使用组合模式时，其叶子和树枝的声明都是实现类，而不是接口，违反了依赖倒置原则。 使用场景：部分、整体场景，如树形菜单，文件、文件夹的管理。 注意事项：定义时为具体类。
    • 享元模式 Flyweight
      • 1) 享元模式(Flyweight Pattern) 也叫蝇量模式:运用共享技术有效地支持大量细粒度的对象 2) 常用于系统底层开发，解决系统的性能问题。像数据库连接池，里面都是创建好的连接对象，在这些连接对象中有我们需要的则直接拿来用，避免重新创建，如果没有我们需要的，则创建一个 3)享元模式能够解决重复对象的内存浪费的问题，当系统中有大量相似对象，需要缓冲池时。不需总是创建新对象，可以从缓冲池里拿。这样可以降低系统内存，同时提高效率 4)享元模式经典的应用场景就是池技术了，String常量池、数据库连接池、缓冲池等等都是享元模式的应用，享元模式是池技术的重要实现方式
    • 装饰器模式 Decorator
      • 装饰器模式（Decorator Pattern）允许向一个现有的对象添加新的功能，同时又不改变其结构。这种类型的设计模式属于结构型模式，它是作为现有的类的一个包装。 这种模式创建了一个装饰类，用来包装原有的类，并在保持类方法签名完整性的前提下，提供了额外的功能。 我们通过下面的实例来演示装饰器模式的用法。其中，我们将把一个形状装饰上不同的颜色，同时又不改变形状类。
      • 介绍
        • 意图：动态地给一个对象添加一些额外的职责。就增加功能来说，装饰器模式相比生成子类更为灵活。 主要解决：一般的，我们为了扩展一个类经常使用继承方式实现，由于继承为类引入静态特征，并且随着扩展功能的增多，子类会很膨胀。 何时使用：在不想增加很多子类的情况下扩展类。 如何解决：将具体功能职责划分，同时继承装饰者模式。 关键代码： 1、Component 类充当抽象角色，不应该具体实现。 2、修饰类引用和继承 Component 类，具体扩展类重写父类方法。 应用实例： 1、孙悟空有 72 变，当他变成"庙宇"后，他的根本还是一只猴子，但是他又有了庙宇的功能。 2、不论一幅画有没有画框都可以挂在墙上，但是通常都是有画框的，并且实际上是画框被挂在墙上。在挂在墙上之前，画可以被蒙上玻璃，装到框子里；这时画、玻璃和画框形成了一个物体。 优点：装饰类和被装饰类可以独立发展，不会相互耦合，装饰模式是继承的一个替代模式，装饰模式可以动态扩展一个实现类的功能。 缺点：多层装饰比较复杂。 使用场景： 1、扩展一个类的功能。 2、动态增加功能，动态撤销。 注意事项：可代替继承。
    • 代理模式 Proxy
      • 1)代理模式:为一个对象提供一个替身，以控制对这个对象的访问。即通过代理对象访问目标对象这样做的好处是:可以在目标对象实现的基础上，增强额外的功能操作即扩展目标对象的功能。 2)被代理的对象可以是远程对象、创建开销大的对象或需要安全控制的对象 3)代理模式有不同的形式，主要有三种静态代理、动态代理(JDK 代理、接口代理)和Cglib 代理(可以在内存动态的创建对象，而不需要实现接口，他是属于动态代理的范畴)。
      • 介绍
        • 意图：为其他对象提供一种代理以控制对这个对象的访问。 主要解决：在直接访问对象时带来的问题，比如说：要访问的对象在远程的机器上。在面向对象系统中，有些对象由于某些原因（比如对象创建开销很大，或者某些操作需要安全控制，或者需要进程外的访问），直接访问会给使用者或者系统结构带来很多麻烦，我们可以在访问此对象时加上一个对此对象的访问层。 何时使用：想在访问一个类时做一些控制。 如何解决：增加中间层。 关键代码：实现与被代理类组合。 应用实例： 1、Windows 里面的快捷方式。 2、猪八戒去找高翠兰结果是孙悟空变的，可以这样理解：把高翠兰的外貌抽象出来，高翠兰本人和孙悟空都实现了这个接口，猪八戒访问高翠兰的时候看不出来这个是孙悟空，所以说孙悟空是高翠兰代理类。 3、买火车票不一定在火车站买，也可以去代售点。 4、一张支票或银行存单是账户中资金的代理。支票在市场交易中用来代替现金，并提供对签发人账号上资金的控制。 5、spring aop。 优点： 1、职责清晰。 2、高扩展性。 3、智能化。 缺点： 1、由于在客户端和真实主题之间增加了代理对象，因此有些类型的代理模式可能会造成请求的处理速度变慢。 2、实现代理模式需要额外的工作，有些代理模式的实现非常复杂。 使用场景：按职责来划分，通常有以下使用场景： 1、远程代理。 2、虚拟代理。 3、Copy-on-Write 代理。 4、保护（Protect or Access）代理。 5、Cache代理。 6、防火墙（Firewall）代理。 7、同步化（Synchronization）代理。 8、智能引用（Smart Reference）代理。 注意事项： 1、和适配器模式的区别：适配器模式主要改变所考虑对象的接口，而代理模式不能改变所代理类的接口。 2、和装饰器模式的区别：装饰器模式为了增强功能，而代理模式是为了加以控制。
      • 静态代理
        • 静态代理在使用时需要定义接口或者父类, 被代理对象(即目标对象)与代理对象一起实现相同的接口或者是继承相同父类 优缺点： 1)优点:在不修改目标对象的功能前提下，能通过代理对象对目标功能扩展. 2)缺点: 因为代理对象需要与目标对象实现一样的接口，所以会有很多代理类 3)一 旦接口增加方法,目标对象与代理对象都要维护
      • 动态代理
        • JDK 代理
          • 1) 代理对象，不需要实现接口，但是目标对象要实现接口，否则不能用动态代理 2)代理对 象的生成，是利用JDK的API，动态的在内存中构建代理对象 3)动态代理 也叫做: JDK 代理、接口代理 实现类图： 
        • Cglib 代理
          • 1) 静态代理和JDK代理模式都要求目标对象是实现一个接口,但是有时候目标对象只是一 个单独的对象,并没有实现任何的接口，这个时候可使用目标对象子类来实现代理-这就 是Cglib代理 2) Cglib 代理也叫作子类代理,它是在内存中构建一个 子类对象从而实现对目标对象功能 扩展,有些书也将Cglib代理归属到动态代理。 3)Cglib是一个强大的高性能的代码生成包,它可以在运行期扩展java类与实现java接口.它 广泛的被许多AOP的框架使用,例如Spring AOP，实现方法拦截 4) 在AOP编程中如何选择代理模式: 1.目标对象需要实现接口，用JDK代理 2.目标对象不需要实现接口，用Cglib代理 5)Cglib包的底层是通过使用字节码处理框架ASM来转换字节码并生成新的类
    • 区别
• 创建型
  • 本质
    • 创建对象的模式：对类的实例化进行抽象
  • 特点
    • 封装了具体类的信息
    • 隐藏了类的实例化过程
  • 5种模式
    • 单例模式 Singleton
      • 单例模式（Singleton Pattern）是 Java 中最简单的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 这种模式涉及到一个单一的类，该类负责创建自己的对象，同时确保只有单个对象被创建。这个类提供了一种访问其唯一的对象的方式，可以直接访问，不需要实例化该类的对象。 注意： 1、单例类只能有一个实例。 2、单例类必须自己创建自己的唯一实例。 3、单例类必须给所有其他对象提供这一实例。
      • 介绍
        • 意图：保证一个类仅有一个实例，并提供一个访问它的全局访问点。 主要解决：一个全局使用的类频繁地创建与销毁。 何时使用：当您想控制实例数目，节省系统资源的时候。 如何解决：判断系统是否已经有这个单例，如果有则返回，如果没有则创建。 关键代码：构造函数是私有的。 应用实例： 1、一个班级只有一个班主任。 2、Windows 是多进程多线程的，在操作一个文件的时候，就不可避免地出现多个进程或线程同时操作一个文件的现象，所以所有文件的处理必须通过唯一的实例来进行。 3、一些设备管理器常常设计为单例模式，比如一个电脑有两台打印机，在输出的时候就要处理不能两台打印机打印同一个文件。 优点： 1、在内存里只有一个实例，减少了内存的开销，尤其是频繁的创建和销毁实例（比如管理学院首页页面缓存）。 2、避免对资源的多重占用（比如写文件操作）。 缺点：没有接口，不能继承，与单一职责原则冲突，一个类应该只关心内部逻辑，而不关心外面怎么样来实例化。 使用场景： 1、要求生产唯一序列号。 2、WEB 中的计数器，不用每次刷新都在数据库里加一次，用单例先缓存起来。 3、创建的一个对象需要消耗的资源过多，比如 I/O 与数据库的连接等。 注意事项：getInstance() 方法中需要使用同步锁 synchronized (Singleton.class) 防止多线程同时进入造成 instance 被多次实例化。
      • 饿汉式
        • 静态常量
          • class Singleton { //1. 构造器私有化, 外部能new private Singleton() { } //2.本类内部创建对象实例 private final static Singleton instance = new Singleton(); //3. 提供一个公有的静态方法，返回实例对象 public static Singleton getInstance() { return instance; } }
        • 静态代码块
          • 原理：类初始化的时 候静态代码块（类初始化）>构造代码块（对象初始化）>构造方法 class Singleton { //1. 构造器私有化, 外部能new private Singleton() { } //2.本类内部创建对象实例 private static Singleton instance; static { // 在静态代码块中，创建单例对象 instance = new Singleton(); } //3. 提供一个公有的静态方法，返回实例对象 public static Singleton getInstance() { return instance; } }
      • 懒汉式
        • 线程不安全
          • class Singleton { private static Singleton instance; private Singleton() {} //提供一个静态的公有方法，当使用到该方法时，才去创建 instance //即懒汉式 public static Singleton getInstance() { if(instance == null) { instance = new Singleton(); } return instance; } }
        • 线程安全
          • 同步代码块
          • 同步方法
            • class Singleton { private static Singleton instance; private Singleton() {} //提供一个静态的公有方法，加入同步处理的代码，解决线程安全问题 //即懒汉式 public static synchronized Singleton getInstance() { if(instance == null) { instance = new Singleton(); } return instance; } }
          • 双重检查
            • // 懒汉式(线程安全，同步方法) class Singleton { private static volatile Singleton instance; private Singleton() {} //提供一个静态的公有方法，加入双重检查代码，解决线程安全问题, 同时解决懒加载问题 //同时保证了效率, 推荐使用 public static Singleton getInstance() { if(instance == null) { synchronized (Singleton.class) { if(instance == null) { instance = new Singleton(); } } } return instance; } }
          • 静态内部类
            • // 静态内部类完成， 推荐使用 class Singleton { private static volatile Singleton instance; //构造器私有化 private Singleton() {} //写一个静态内部类,该类中有一个静态属性 Singleton private static class SingletonInstance { private static final Singleton INSTANCE = new Singleton(); } //提供一个静态的公有方法，直接返回SingletonInstance.INSTANCE public static synchronized Singleton getInstance() { return SingletonInstance.INSTANCE; } }
          • 枚举
            • enum Singleton { INSTANCE; //属性 public void sayOK() { System.out.println("ok~"); } }
    • 原型模式 Prototype
      • 原型模式（Prototype Pattern）是用于创建重复的对象，同时又能保证性能。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 这种模式是实现了一个原型接口，该接口用于创建当前对象的克隆。当直接创建对象的代价比较大时，则采用这种模式。例如，一个对象需要在一个高代价的数据库操作之后被创建。我们可以缓存该对象，在下一个请求时返回它的克隆，在需要的时候更新数据库，以此来减少数据库调用。
      • 介绍
        • 意图：用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。 主要解决：在运行期建立和删除原型。 何时使用： 1、当一个系统应该独立于它的产品创建，构成和表示时。 2、当要实例化的类是在运行时刻指定时，例如，通过动态装载。 3、为了避免创建一个与产品类层次平行的工厂类层次时。 4、当一个类的实例只能有几个不同状态组合中的一种时。建立相应数目的原型并克隆它们可能比每次用合适的状态手工实例化该类更方便一些。 如何解决：利用已有的一个原型对象，快速地生成和原型对象一样的实例。 关键代码： 1、实现克隆操作，在 JAVA 继承 Cloneable，重写 clone()，在 .NET 中可以使用 Object 类的 MemberwiseClone() 方法来实现对象的浅拷贝或通过序列化的方式来实现深拷贝。 2、原型模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些"易变类"拥有稳定的接口。 应用实例： 1、细胞分裂。 2、JAVA 中的 Object clone() 方法。 优点： 1、性能提高。 2、逃避构造函数的约束。 缺点： 1、配备克隆方法需要对类的功能进行通盘考虑，这对于全新的类不是很难，但对于已有的类不一定很容易，特别当一个类引用不支持串行化的间接对象，或者引用含有循环结构的时候。 2、必须实现 Cloneable 接口。 注意事项：与通过对一个类进行实例化来构造新对象不同的是，原型模式是通过拷贝一个现有对象生成新对象的。浅拷贝实现 Cloneable，重写，深拷贝是通过实现 Serializable 读取二进制流。
      • 使用场景
        • 使用场景： 1、资源优化场景。 2、类初始化需要消化非常多的资源，这个资源包括数据、硬件资源等。 3、性能和安全要求的场景。 4、通过 new 产生一个对象需要非常繁琐的数据准备或访问权限，则可以使用原型模式。 5、一个对象多个修改者的场景。 6、一个对象需要提供给其他对象访问，而且各个调用者可能都需要修改其值时，可以考虑使用原型模式拷贝多个对象供调用者使用。 （实现Cloneable,调用clone接口） 7、在实际项目中，原型模式很少单独出现，一般是和工厂方法模式一起出现，通过 clone 的方法创建一个对象，然后由工厂方法提供给调用者。原型模式已经与 Java 融为浑然一体，大家可以随手拿来使用。
    • 建造者模式 Builder
      • 1)建造者模式(BuilderPattern)又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来(抽象类别)，使这个抽象过程的不同实现方法可以构造出不同表现(属性)的对象。 2)建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。 
      • 使用场景
        • 如果一个类中有很多属性，为了避免构造函数的参数列表过长，影响代码的可读性和易用性，我们可以通过构造函数配合 set() 方法来解决。但是，如果存在下面情况中的任意一种，我们就要考虑使用建造者模式了。
        • 强制创建对象
          • 我们把类的必填属性放到构造函数中，强制创建对象的时候就设置。如果必填的属性有很多，把这些必填属性都放到构造函数中设置，那构造函数就又会出现参数列表很长的问题。如果我们把必填属性通过 set() 方法设置，那校验这些必填属性是否已经填写的逻辑就无处安放了。
        • 属性之间有一定的依赖关系或者约束条件
          • 如果类的属性之间有一定的依赖关系或者约束条件，我们继续使用构造函数配合 set() 方法的设计思路，那这些依赖关系或约束条件的校验逻辑就无处安放了。
        • 创建不可变对象
          • 如果我们希望创建不可变对象，也就是说，对象在创建好之后，就不能再修改内部的属性值，要实现这个功能，我们就不能在类中暴露 set() 方法。构造函数配合 set() 方法来设置属性值的方式就不适用了。
      • 例子
    • 工厂模式
      • 简单工厂模式
      • 工厂方法模式 Factory Method
        • 工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。
        • 介绍
          • 意图：定义一个创建对象的接口，让其子类自己决定实例化哪一个工厂类，工厂模式使其创建过程延迟到子类进行。 主要解决：主要解决接口选择的问题。 何时使用：我们明确地计划不同条件下创建不同实例时。 如何解决：让其子类实现工厂接口，返回的也是一个抽象的产品。 关键代码：创建过程在其子类执行。 应用实例： 1、您需要一辆汽车，可以直接从工厂里面提货，而不用去管这辆汽车是怎么做出来的，以及这个汽车里面的具体实现。 2、Hibernate 换数据库只需换方言和驱动就可以。 优点： 1、一个调用者想创建一个对象，只要知道其名称就可以了。 2、扩展性高，如果想增加一个产品，只要扩展一个工厂类就可以。 3、屏蔽产品的具体实现，调用者只关心产品的接口。 缺点：每次增加一个产品时，都需要增加一个具体类和对象实现工厂，使得系统中类的个数成倍增加，在一定程度上增加了系统的复杂度，同时也增加了系统具体类的依赖。这并不是什么好事。 使用场景： 1、日志记录器：记录可能记录到本地硬盘、系统事件、远程服务器等，用户可以选择记录日志到什么地方。 2、数据库访问，当用户不知道最后系统采用哪一类数据库，以及数据库可能有变化时。 3、设计一个连接服务器的框架，需要三个协议，"POP3"、"IMAP"、"HTTP"，可以把这三个作为产品类，共同实现一个接口。 注意事项：作为一种创建类模式，在任何需要生成复杂对象的地方，都可以使用工厂方法模式。有一点需要注意的地方就是复杂对象适合使用工厂模式，而简单对象，特别是只需要通过 new 就可以完成创建的对象，无需使用工厂模式。如果使用工厂模式，就需要引入一个工厂类，会增加系统的复杂度。
        • 例子
          • spring可以通过IOC建造一个工厂模式
      • 抽象工厂模式 Abstract Factory
        • 抽象工厂模式（Abstract Factory Pattern）是围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 在抽象工厂模式中，接口是负责创建一个相关对象的工厂，不需要显式指定它们的类。每个生成的工厂都能按照工厂模式提供对象。
        • 介绍
          • 意图：提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。 主要解决：主要解决接口选择的问题。 何时使用：系统的产品有多于一个的产品族，而系统只消费其中某一族的产品。 如何解决：在一个产品族里面，定义多个产品。 关键代码：在一个工厂里聚合多个同类产品。 应用实例：工作了，为了参加一些聚会，肯定有两套或多套衣服吧，比如说有商务装（成套，一系列具体产品）、时尚装（成套，一系列具体产品），甚至对于一个家庭来说，可能有商务女装、商务男装、时尚女装、时尚男装，这些也都是成套的，即一系列具体产品。假设一种情况（现实中是不存在的，要不然，没法进入共产主义了，但有利于说明抽象工厂模式），在您的家中，某一个衣柜（具体工厂）只能存放某一种这样的衣服（成套，一系列具体产品），每次拿这种成套的衣服时也自然要从这个衣柜中取出了。用 OOP 的思想去理解，所有的衣柜（具体工厂）都是衣柜类的（抽象工厂）某一个，而每一件成套的衣服又包括具体的上衣（某一具体产品），裤子（某一具体产品），这些具体的上衣其实也都是上衣（抽象产品），具体的裤子也都是裤子（另一个抽象产品）。 优点：当一个产品族中的多个对象被设计成一起工作时，它能保证客户端始终只使用同一个产品族中的对象。 缺点：产品族扩展非常困难，要增加一个系列的某一产品，既要在抽象的 Creator 里加代码，又要在具体的里面加代码。 使用场景： 1、QQ 换皮肤，一整套一起换。 2、生成不同操作系统的程序。 注意事项：产品族难扩展，产品等级易扩展。
• 行为型
  • 本质
    • 对在不同的对象之间划分责任和算法的抽象
  • 两种类型
    • 类结构类型
      • 使用继承关系在几个类之间分配行为
    • 对象结构类型
      • 使用对象聚合的方式来分配行为
  • 11种模式
    • 模板方法模式 Template Method
      • 在模板模式（Template Pattern）中，一个抽象类公开定义了执行它的方法的方式/模板。它的子类可以按需要重写方法实现，但调用将以抽象类中定义的方式进行。这种类型的设计模式属于行为型模式。
      • 介绍
        • 意图：定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤。 主要解决：一些方法通用，却在每一个子类都重新写了这一方法。 何时使用：有一些通用的方法。 如何解决：将这些通用算法抽象出来。 关键代码：在抽象类实现，其他步骤在子类实现。 应用实例： 1、在造房子的时候，地基、走线、水管都一样，只有在建筑的后期才有加壁橱加栅栏等差异。 2、西游记里面菩萨定好的 81 难，这就是一个顶层的逻辑骨架。 3、spring 中对 Hibernate 的支持，将一些已经定好的方法封装起来，比如开启事务、获取 Session、关闭 Session 等，程序员不重复写那些已经规范好的代码，直接丢一个实体就可以保存。 优点： 1、封装不变部分，扩展可变部分。 2、提取公共代码，便于维护。 3、行为由父类控制，子类实现。 缺点：每一个不同的实现都需要一个子类来实现，导致类的个数增加，使得系统更加庞大。 使用场景： 1、有多个子类共有的方法，且逻辑相同。 2、重要的、复杂的方法，可以考虑作为模板方法。 注意事项：为防止恶意操作，一般模板方法都加上 final 关键词。
    • 命令模式 Command
      • 命令模式 的 一个思想是将命令的 请求者 和 命令的实现者进行解耦 
    • 迭代器模式 Iterator
      • 如果我们的集合元素是用不同的方式实现的，有数组，还有java 的集合类，或者还有其他方式，当客户端要遍历这些集合元素的时候就要使用多种遍历方式,而且还会暴露元素的内部结构,可以考虑使用迭代器模式解决。
    • 观察着模式 Observer
      • 当对象间存在一对多关系时，则使用观察者模式（Observer Pattern）。比如，当一个对象被修改时，则会自动通知依赖它的对象。观察者模式属于行为型模式。
      • 介绍
        • 意图：定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并被自动更新。 主要解决：一个对象状态改变给其他对象通知的问题，而且要考虑到易用和低耦合，保证高度的协作。 何时使用：一个对象（目标对象）的状态发生改变，所有的依赖对象（观察者对象）都将得到通知，进行广播通知。 如何解决：使用面向对象技术，可以将这种依赖关系弱化。 关键代码：在抽象类里有一个 ArrayList 存放观察者们。 应用实例： 1、拍卖的时候，拍卖师观察最高标价，然后通知给其他竞价者竞价。 2、西游记里面悟空请求菩萨降服红孩儿，菩萨洒了一地水招来一个老乌龟，这个乌龟就是观察者，他观察菩萨洒水这个动作。 优点： 1、观察者和被观察者是抽象耦合的。 2、建立一套触发机制。 缺点： 1、如果一个被观察者对象有很多的直接和间接的观察者的话，将所有的观察者都通知到会花费很多时间。 2、如果在观察者和观察目标之间有循环依赖的话，观察目标会触发它们之间进行循环调用，可能导致系统崩溃。 3、观察者模式没有相应的机制让观察者知道所观察的目标对象是怎么发生变化的，而仅仅只是知道观察目标发生了变化。 使用场景： 一个抽象模型有两个方面，其中一个方面依赖于另一个方面。将这些方面封装在独立的对象中使它们可以各自独立地改变和复用。 一个对象的改变将导致其他一个或多个对象也发生改变，而不知道具体有多少对象将发生改变，可以降低对象之间的耦合度。 一个对象必须通知其他对象，而并不知道这些对象是谁。 需要在系统中创建一个触发链，A对象的行为将影响B对象，B对象的行为将影响C对象……，可以使用观察者模式创建一种链式触发机制。 注意事项： 1、JAVA 中已经有了对观察者模式的支持类。 2、避免循环引用。 3、如果顺序执行，某一观察者错误会导致系统卡壳，一般采用异步方式。
    • 调停者模式 Mediator
    • 状态模式 State
      • 意图
        • 允许对象在内部状态改变时改变它的行为，对象看起来好像修改了它所属的类。
      • 类图
      • 实现
    • 策略模式 Strategy
      • 策略模式(strategy pattern): 定义了算法族, 分别封闭起来, 让它们之间可以互相替换, 此模式让算法的变化独立于使用算法的客户
      • 介绍
        • 意图：定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。 主要解决：在有多种算法相似的情况下，使用 if...else 所带来的复杂和难以维护。 何时使用：一个系统有许多许多类，而区分它们的只是他们直接的行为。 如何解决：将这些算法封装成一个一个的类，任意地替换。 关键代码：实现同一个接口。 应用实例： 1、诸葛亮的锦囊妙计，每一个锦囊就是一个策略。 2、旅行的出游方式，选择骑自行车、坐汽车，每一种旅行方式都是一个策略。 3、JAVA AWT 中的 LayoutManager。 优点： 1、算法可以自由切换。 2、避免使用多重条件判断。 3、扩展性良好。 缺点： 1、策略类会增多。 2、所有策略类都需要对外暴露。 使用场景： 1、如果在一个系统里面有许多类，它们之间的区别仅在于它们的行为，那么使用策略模式可以动态地让一个对象在许多行为中选择一种行为。 2、一个系统需要动态地在几种算法中选择一种。 3、如果一个对象有很多的行为，如果不用恰当的模式，这些行为就只好使用多重的条件选择语句来实现。 注意事项：如果一个系统的策略多于四个，就需要考虑使用混合模式，解决策略类膨胀的问题。
      • 类图
      • 与状态模式的比较
        • 状态模式的类图和策略模式类似，并且都是能够动态改变对象的行为。但是状态模式是通过状态转移来改变 Context 所组合的 State 对象，而策略模式是通过 Context 本身的决策来改变组合的 Strategy 对象。所谓的状态转移，是指 Context 在运行过程中由于一些条件发生改变而使得 State 对象发生改变，注意必须要是在运行过程中。 状态模式主要是用来解决状态转移的问题，当状态发生转移了，那么 Context 对象就会改变它的行为；而策略模式主要是用来封装一组可以互相替代的算法族，并且可以根据需要动态地去替换 Context 使用的算法。
      • 实现
      • 实例
        • 使用策略模式优化查询
          • 需求背景 一个需求是老带新发积分，原来的人写了一个后台数据统计的功能，但随着业务发展数据量多了一些后，页面 的查询速度就比较慢了。并交给我进行优化 问题分析 通过对该页面查询功能分析发现使用的索引是没有问题的，慢的原因 是因为关联了过多的表（7个） 有些副表就只使用了一个字段，我当时思考能不能把这些表去掉，来减少关联提升查询速度，结果产品的回答是 不可以。既然不可以那只有，先少量的表进行关联，再使用分页，把其他的数据添加进去 解决问题： 使用策略模式，将查询分为几组，无查询条件的查询，老客与新客相关属性的查询，顾客购买的组织相关的查询 全条件的查询 根据不同的查询条件选择策略
    • 责任链模式 Chain of Responsibility
      • 1)职责链模式(Chain of Responsibility Pattem)，又叫责任链模式，为请求创建了一个接收者对象的链。这种模式对请求的发送者和接收者进行解耦。 2)职责链模式通常每个接收者都包含对另一个接收者的引用。如果一个对象不能处理该请求，那么它会把相同的
      • 类图
        • 
    • 访问者模式 Visitor
    • 备忘录模式 Memento
    • 解释器模式Interpreter
• 组合使用
  • 工厂模式与策略模式 结合使用
    • 工厂模式根据具体的配置获得具体的实现类 然后set到策略模式的content中进行具体的调用