设计模式概述

1. 设计模式的目的

   • 代码重用性：相同功能的代码，不用多次编写
   • 代码可读性：编程规范, 便于其他程序员的阅读和理解
   • 可扩展性：当需要增加新功能时，非常方便
   • 可靠性：当增加新功能后，对原功能没有影响
   • 使程序呈现高内聚，低耦合

2. 设计模式在软件中用在哪里？

   • 面向对象 -> 功能模块（设计模式、算法、数据结构）-> 框架（设计模式）-> 架构（服务器集群）

3. 面向对象设计

   • 对接口编程而不是对实现编程
   • 优先使用对象组合而不是继承
     • 白箱复用 – 类继承 – 父类的内部细节对子类可见
     • 黑箱复用 – 对象组合 – 对象的内部细节不可见

4. 设计模式的七大原则

   1. 单一职责原则（Single Responsibility Principle）
      • 单个接口或类只负责一个功能领域中的相应职责，而不应该有多个职责。尽可能划分职责，再通过组合来实现复杂业务。
      • 注意事项
        • 降低类的复杂度，一个类只负责一项职责
        • 提高类的可读性、可维护性
        • 减低变更引起的风险
        • 通常情况下都应遵守单一职责原则。只有逻辑足够简单，才可以在代码级违反单一职责原则；当类中方法的数量足够少，可以在方法级别保持单一职责原则
   2. 开闭原则（Open Close Principle）
      • 对扩展开放(对提供方)，对修改关闭(对使用方)
      • 用抽象构建框架，用实现扩展细节
      • 当软件需要变化时，尽量通过扩展软件实体来实现，而不是修改已有代码
   3. 里氏代换原则（Liskov Substitution Principle）
      • 如果一个类被其他类所继承，则修改这个类时，必须考虑其所有子类。同时父类修改后，所有涉及到子类的功能都有可能产生故障
      • 任何基类可以出现的地方，子类一定可以出现。即，所有引用基类的地方必须能透明地使用其子类的对象。即，用子类替换父类对之前用父类的地方无影响
      • 在使用继承时，遵循里氏替换原则，在子类中尽量不要重写父类的方法，可适当通过聚合、组合、依赖解决
   4. 依赖倒转原则（Dependence Inversion Principle）
      • 高层模块不应该依赖低层模块，二者都应该依赖其抽象
      • 抽象不应该依赖细节，细节应该依赖抽象
      • 依赖倒转(倒置)的中心思想是面向接口编程
      • java中抽象指的是接口或抽象类，细节就是具体的实现类。制定好规范，而不涉及任何具体的操作，把展现细节的任务交给他们的实现类去完成。以抽象为基础搭建的架构比以细节为基础的架构要更稳定
      • 依赖关系传递的三种方式：接口传递、构造方法传递、setter方式传递
      • 注意事项
        • 低层模块尽量都要有抽象类或接口，或者两者都有，程序稳定性更好
        • 变量的声明类型尽量是抽象类或接口, 变量引用和实际对象间存在一个缓冲层，利于程序扩展和优化
        • 继承时遵循里氏代换原则
   5. 接口隔离原则（Interface Segregation Principle）
      • 使用多个隔离的接口，比使用单个接口要好
      • 降低类之间的耦合度
   6. 迪米特法则，又称最少知道原则（Demeter Principle）
      • 一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立
      • 一个类对自己依赖的类知道的越少越好。对于被依赖的类不管多么复杂，都尽量将逻辑封装在类的内部，对外只提供public方法，不泄露任何其他信息
      • 我们称出现成员变量、方法参数、方法返回值中的类为直接朋友，迪米特法则即只与直接朋友通信
      • 出现在局部变量中的类不是直接朋友，即陌生类最好不要以局部变量的形式出现在类的内部
      • 核心是降低类之间的耦合，减少不必要的依赖，但并不是要求完全没有依赖关系
   7. 合成复用原则（Composite Reuse Principle）
      • 尽量使用合成/聚合的方式，而不是使用继承

5. 设计模式的分类

   • 创建型模式：单例模式、抽象工厂模式、原型模式、建造者模式、工厂模式
   • 结构型模式：适配器模式、桥接模式、装饰模式、组合模式、外观模式、享元模式、代理模式
   • 行为型模式：模版方法模式、命令模式、访问者模式、迭代器模式、观察者模式、中介者模式、备忘录模式、解释器模式、状态模式、策略模式、职责链模式