Java设计模式学习笔记

软件工程中，设计模式是对软件设计中普遍存在（反复出现）的各种问题，所提出的解决方案。由建筑设计领域引入到计算机科学的。是站在结构性、扩展性、稳定性、复用性的角度上考虑，而不是功能实现的角度考虑。

——设计模式常用七大原则

1. 单一职责原则

• 基本介绍：对类来说，即一个类应该只负责一项职责，如类A负责两个不同的职责：职责1和职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。
• 注意事项和细节：
  1. 降低类的复杂度，一个类只负责一项职责
  2. 提高类的可读性，可维护性
  3. 降低变更引起的风险
  4. 通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反职责原则；只有类中方法数据足够少，可以在方法级别保持单一职责原则

2. 接口隔离原则

• 基本介绍：客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上

3. 依赖倒转（倒置）原则

• 基本介绍：
  • 高层模块不应该依赖低层模块，二者都应该依赖其抽象
  • 抽象不应该依赖细节，细节应该依赖抽象
  • 依赖倒转的中心思想是面向接口编程
  • 设计理念：相对于细节的多变性，抽象的东西要稳定的多。以抽象为基础搭建的架构要比细节为基础搭建的架构要稳定的多。在java中，抽象指的是接口和抽象类，细节就是具体的实现类。
  • 使用接口或抽象类的目的是制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成
• 依赖关系传递的方式
  • 接口传递
  • 构造器传递
  • setter方法传递
• 注意的细节：
  • 低层模块尽量都要有抽象类或者接口，或者两者都有，程序的稳定性会更好
  • 变量的声明类型尽量是抽象类或接口，这样我们的变量引用和实际对象间存在一个缓冲层，利于程序的扩展和优化
  • 继承时遵循里式替换原则

4. 里式替换原则

• 思考：
  • 继承：父类中凡是已经实现好的方法，实际上是在设定规范和契约，虽然它不强制要求所有的子类必须遵守这些契约，但是如果子类对这些已经实现的方法做任意的修改，就会对整个继承体系造成破坏
  • 继承会给程序带来入侵性，程序的可移植性降低，增加对象之间的耦合度，当类需要修改时，必须考虑所有的子类，并且父类修改后，所有涉及到的子类的功能都有可能产生故障
• 基本介绍：
  • 所有引用基类的地方必须能透明地使用其子类的对象
  • 在使用继承时，遵循里式替换原则，在子类中尽量不要重写父类的方法
  • 继承实际上让两个类耦合性增强了，在适当的情况下，可以通过聚合，组合，依赖来解决问题（原来的父类和子类都继承一个更通俗的基类）

5. 开闭原则 ocp

• 基本介绍：
  • 是编程中最基础、最重要的设计原则
  • 一个软件实体类，模块和函数应该对扩展开放（对提供方） ，对修改关闭（使用方）。用抽象类构建框架，用实现扩展细节
  • 当软件需要变化时，尽量通过扩展软件实体的行为来实现变化，而不是通过修改已有的代码来实现变化
  • 编程中遵循其他原则，以及使用设计模式的目的就是遵循开闭原则
  • 实现：把父类做成抽象类，提供共有的方法，让子类实现即可，这样增加功能时，使用方就不需要修改代码

6. 迪米特法则

• 基本介绍：

  • 一个对象应该对其他对象保持最少的了解
  • 类和类关系越密切，耦合度越大
  • 又叫最少知道原则，即一个类对自己依赖的类知道的越少越好。也就是说，对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部。对外除乐提供public方法，不对外泄漏任何信息
  • 只是和直接的朋友通信
  • 直接朋友：每个对象都会和其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合的方式有很多，依赖，关联，组合，聚合等。我们称出现成员变量、方法参数、方法返回值中的类为直接朋友，而出现在局部变量中的类为陌生类。也就是说，陌生的类最好不要以局部变量的形式出现在类的内部。

• 注意事项和细节：

  • 迪米特法则的核心是降低类之间的耦合
  • 由于每个类都减少了不必要的依赖，因此迪米特法则只是要求降低类之间的耦合关系，并不是要求完全没有依赖关系

7. 合成复用原则

• 基本介绍：
  • 尽量使用合成 / 聚合的方式，而不是使用继承

设计原则核心思想

1. 找出应用中可能需要变化之处，把它们独立出来，不要和那些不需要变化的代码混合在一起
2. 针对接口编程，而不是针对实现编程
3. 为了交互对象之间的松耦合设计而努力

——常用设计模式类型

1. 创建型模式

1.1 单例模式

饿汉式（静态常量）

• 优点：写法简单，在类装载的过程中就完成了实例化。避免了线程同步问题。
• 缺点：在类装载的时候就完成实例化，没有达到懒加载的效果。如果从一开始就没有用过这个实例，就会造成内存的浪费
• 这种方式基于类加载机制避免了多线程的同步问题，不过，instance在类装载时就实例化，在单例模式中大多数都是调用getInstance方法，但是导致类加载的方式有很多，因此不确定有没有其他的方式（或者是其他的静态方法）导致类装载，这时候初始化instance就没有达到lazy loading的效果
• 结论：这种单例模式可用，可能会造成内存浪费

饿汉式（静态代码块）

• 优缺点：和上面方法类似，只不过将实例化的过程放到了静态代码块中，也是在类装载的时候，就执行静态代码块中的代码，初始化类的实例。优缺点和上面一样。
• 结论：这种单例模式可用，但是可能造成内存的浪费。

懒汉式（线程不安全）

• 优点：起到了懒加载的效果，不会造成内存的浪费，但是只能在单线程下使用
• 缺点：如果在多线程下，一个线程进入了if（single == null）判断语句，还未来得及往下执行，另一个线程也通过了这个判断语句，这时就会产生多个实例。所以在多线程环境下不可使用这种方式
• 结论：在实际开发中，不可使用这种方式

懒汉式（线程安全，同步方法）

• 优点：解决了线程不安全的问题，不造成内存的浪费，可在多线程下使用
• 缺点：效率低，每个线程在想获得类的实例化时，执行getInstance()方法都要进行同步。而其实这个方法只执行一次就够了，后面想获得该类的实例，直接return就行了。方法进行同步效率太低
• 结论：在实际开发中，不推荐使用这种方式

懒汉式（线程安全，同步代码块）

• 缺点：在if判断加同步代码块根本解决不了线程同步的作用。跟第三种方式遇到的情形一样，假如一个线程进入了if（single == null）的判断，还未来得及往下执行，另一个线程也通过了这个判断语句，这时就会产生多个实例
• 结论：在实际开发中，不能使用这种方式

双重检查

• 优点：该方式是多线程开发中常用的，代码中进行两次if（single == null）检查，加上volatile关键字，这样可以保证线程的安全性
• 这样，实例化代码只用执行一次，后面再次访问时，判断if（singel == null）直接return实例化对象，也避免的反复进行方法同步
• 线程安全，延迟加载，效率提高
• 结论：在实际开发中，推荐使用这种单例设计模式

静态内部类

• 优点：这种方式采用了类装载的机制，保证了初始化实例时只有一个线程
• 静态内部类在类装载时不会立即实例化，而是在需要实例化时，调用getInstance方法，才会装载静态内部类，从而完成类实例化
• 类的静态属性只会在第一次加载类的时候初始化，在这里JVM保证了线程的安全性，在类进行初始化时，别的线程是无法进入的
• 避免了线程不安全，利用静态内部类特点实现延迟加载，效率高
• 结论：推荐使用

枚举

• 优点：借助jdk1.5中添加的枚举来实现单例模式。不仅能避免多线程同步问题，还能防止反序列化重新创建对象，Effective Java 作者提倡的方式
• 结论：推荐使用

单例模式在JDK源码的应用
Runtime类采用的是单例模式-饿汉式（静态常量）

注意事项和细节说明

• 单例模式保证了系统内存中该类只存在一个对象，节省了系统资源，对于一些需要频繁创建销毁的对象，使用单例模式可以提高性能
• 当想实例化一个单例类的时候，必须要记住使用相应的获取对象的方法，而不是使用new
• 单例模式使用的场景：需要频繁的进行创建和销毁的对象，创建对象时耗时过多或耗费资源过多（重量级对象），但又经常用到的对象，工具类对象、频繁访问数据库或文件的对象

1.2 工厂模式

简单工厂（静态工厂）模式

• 简单工厂模式是属于创建型模式，是工厂模式的一种。简单工厂模式是由一个工厂对象决定创建出哪一种产品类的实例。简单工厂模式是工厂模式家族中最简单实用的模式
• 简单工厂模式：定义了一个创建对象的类，由这个类来封装实例化对象的行为
• 在软件开发中，当我们会用到大量的创建某种、某类或者某批对象时，就会使用到工厂模式

工厂方法模式

• 定义了一个创建对象的抽象方法，由子类决定要实例化的对象。工厂方法模式将对象的实例化推迟到子类。

抽象工厂模式

• 定义了一个interface用于创建相关或者有依赖关系的对象簇，而无需指明具体的类
• 抽象工厂模式可以将简单工厂模式和工厂方法模式进行整合
• 从设计层面上来看，抽象工厂模式就是对简单工厂模式的改进（进一步的抽象）
• 将工厂抽象成两层，AbstractFactory和具体实现的工厂子类。程序员可以根据创建对象类型使用对应的工厂子类。这样将单个的简单工厂类变成了工厂簇，更利于代码的维护和扩展。

小结

• 工厂模式的意义：将实例化的代码提取出来，放到一个类中进行统一管理和维护，达到和主项目的依赖关系解耦。从而提高项目的扩展和维护性
• 设计模式的依赖抽象原则
• 创建对象实例时，不要直接 new 类，而是把这个 new 类的动作放在一个工厂的方法中并返回。变量不要直接持有具体类的引用
• 不要让类继承具体类，而是继承抽象类或者是实现interface
• 不要覆盖基类中已经实现的方法
• JDK源码应用：Calendar.getInstance() 使用的是简单工厂模式获取到的地区时间

1.3 建造者模式

基本介绍

• 建造者模式又叫生成器模式，是一种对象构建模式。它可以将复杂对象的建造过程抽象出来（抽象类别），使这个抽象过程的不同实现方法可以构造出不同表现（属性）的对象
• 建造者模式是一步一步创建一个复杂的对象，它允许用户只通过指定复杂对象的类型和内容就可以构建它们，用户不需要知道内部的具体构建细节。

JDK源码应用StringBuilder：

• Appendable接口定义了多个append方法（抽象方法），即Appendable为抽象建造者，定义了抽象方法
• AbstractStringBuilder实现了Appendable接口方法，这里的AbstractStringBuilder已经是建造者，只是不能实例化
• StringBuilder即充当了指挥者角色，同时充当了具体的建造者，建造方法的实现是由AbstractStringBuilder完成，而StringBuilder继承了AbstractStringBuilder

1.4 原型模式

• 基本介绍：
  Java中Object类是所有类的根类，Object类提供了一个clone()的方法，该方法可以将一个Java对象复制一份，但是需要实现clone的Java类必须要实现一个接口Cloneable，该接口表示该类能够复制且具有复制的能力

• 浅拷贝

  • 对于数据类型是基本数据类型的成员变量，浅拷贝会直接进行值传递，也就是将该属性值复制一份给新的对象
  • 对于数据类型是引用类型的成员变量，比如说成员变量是某个数组、某个类的对象，那么浅拷贝会进行引用传递，也就是只是将该成员变量的引用值（内存地址）复制一份给新的对象。因为实际上两个对象的该成员变量都指向同一个实例。在这种情况下，在一个对象中修改该成员变量会影响到另一个对象的该成员变量值
  • 浅拷贝是使用默认的clone()方法实现

• 深拷贝

  • 复制对象的所有基本数据类型的成员变量值
  • 为所有引用数据类型的成员变量申请存储空间，并复制每个引用数据类型成员变量所引用的对象，直到该对象可达的所有对象。也就是说，对象进行深拷贝要求对整个对象进行拷贝
  • 实现方式1：重写clone方法实现深拷贝
  • 实现方式2：通过对象的序列化实现深拷贝

• Spring源码应用：在spring中原型（scope=“prototype”）bean的创建，就是原型模式的应用

2. 结构型模式

2.1 适配器模式

基本介绍

• 适配器模式将某个类的接口转换成客户端期望的另一个接口表示，主要目的是兼容性，将原本因接口不匹配不能一起工作的两个类可以协同工作。别名为包装器
• 主要分为三类：类适配器模式，对象适配器模式，接口适配器模式

工作原理

• 适配器模式：将一个类的接口转换成另一种接口，让原本接口不兼容的类可以兼容
• 从用户的角度看不到被适配者，是解耦的
• 用户调用适配器转换出来的目标接口方法，适配器再调用被适配器的相关接口方法
• 用户收到反馈结果，感觉只是和目标接口交互

类适配器模式

• Java是单继承，所以类适配器需要继承src类，这算是一个缺点，因为这要求dst必须是接口，有一定的局限性
• src类的方法在Adapter中会暴露出来，也增加了使用成本
• 由于其继承了src类，所以它可以根据需求重写src类的方法，使得Adapter的灵活性增强

对象适配器模式

• 对象适配器模式和类适配器模式其实算是同一种思想，只不过实现方式不同。根据合成复用原则，使用组合代替继承，所以它解决了类适配器必须继承src的局限性问题，也不要求dst必须是接口
• 使用成本更低，更灵活

接口适配器模式

• 也叫缺省适配器模式
• 当不需要实现全部接口提供的方法时，可先设计一个抽象类实现接口，并为该接口中的每个方法提供一个默认实现（空方法），那么该抽象类的子类可有选择地重写父类的某些方法来实现需求
• 适用于一个接口不想使用其所有的方法的情况

SpringMVC应用：在SpringMVC工作流程中Handler应用了适配器模式

2.2 外观（过程）模式

基本介绍

• 外观模式为子系统中的一组接口提供一个一致的界面，此模式定义了一个高层接口，这个接口使得这一子系统更加容易使用
• 外观模式通过定义一个一致的接口，用以屏蔽内部子系统的细节，使得调用端只需跟这个接口发生调用，而无需关心这个子系统的内部细节

角色

• 外观类：为调用接口提供统一的调用接口，外观类知道哪些子系统负责处理请求，从而将调用端的请求代理给适当子系统对象
• 调用者：外观接口的调用者
• 子系统的集合：指模块或者子系统，处理facade对象指派的任务，他是功能的实际提供者

Mybatis应用：在Mybatis中的Configuration中应用到外观模式

注意事项和细节

• 外观模式屏蔽了子系统的细节，因此外观模式降低了客户端对子系统使用的复杂性
• 外观模式降低了客户端和子系统的耦合关系，让子系统的内部模块更易维护和扩展
• 通过合理的使用外观模式，可以帮我们更好的划分层次
• 当子系统需要进行分层设计时，可以考虑使用Facade模式
• 当维护一个遗留的大型系统时，可能这个系统已经变得非常难以维护和扩展，此时可以考虑为新系统开发一个Facade类，来提供遗留系统的比较清晰的接口，让新系统与Facade类交互，提高复杂性
• 不能过多的或者不合理的使用外观模式，使用外观模式好，还是直接调用模块好，要让系统有层次性，利于维护为目的。

3. 行为型模式

3.1 迭代器模式

基本介绍

• 迭代器模式是常用的设计模式，属于行为型模式
• 如果我们的集合元素是用不同的方式实现的，有数组，还有Java的集合类或者还有其他方式，当客户端要遍历这些集合元素的时候要使用多种遍历方式，而且还会暴露元素的内部结构，可以考虑使用迭代器模式解决
• 迭代器模式，提供一种遍历集合元素的统一接口，用一致的方法遍历集合元素，不需要知道集合对象的底层表示，即：不暴露其内部的结构

在JDK源码应用：ArrayList中的内部类Itr充当了具体迭代器Iterator的类，作为ArrayList内部类，迭代器模式解决了不同集合（ArrayList，Linklist）统一遍历的问题

3.2 观察者模式

基本介绍

• 对象之间多一对依赖的一种设计方案，被依赖的对象为Subject，依赖的对象为Observe，Subject通知Observe变化
• 观察者模式设计后，会以集合的方式管理用户，包括注册，移除和通知
• 增加观察者，就不需要修改核心类，遵守了OCP原则