UML

• 泛化（继承非抽象类）：带空心三角形的直线表示
• 实现（继承抽象类，类实现接口）：带空心三角形的虚线表示
• 依赖：类与类之间最弱的关系，依赖可以简单的理解一个类使用了另一个类：带箭头的虚线表示依赖
• 关联：一个类和另一类有联系：带箭头的实线表示

关联关系是一种包含关系，在UML中用一个带箭头的实线表示，箭头指向被包含类。在UML类中有如下几种。1..1：表示另一个类的一个对象只与该类的一个对象有关系0..*：表示另一个类的一个对象与该类的零个或多个对象有关系1..*：表示另一个类的一个对象与该类的一个或多个对象有关系0..1：表示另一个类的一个对象没有或只与该类的一个对象有关系*  ：任意多个对象关联

• 聚合：表示整体与部分的关系，但是部分可以脱离整体而存在：带空心菱形的直线加箭头表示，has-a关系
• 组合：部分和整体的关系，但是部分存活周期受到整体的影响，若整体不存在则部分也将不存在。此时部分需在整体的构造方法中创建：带实心菱形的直线加箭头表示。
• 关系所表现的强弱程度依次为：组合>聚合>关联>依赖；

软件设计七大原则

• 开闭原则:对扩展开放，对修改封闭。在程序需要进行拓展的时候，不能去修改原有的代码，而是要扩展原有代码，实现一个热插拔的效果。所以一句话概括就是：为了使程序的扩展性好，易于维护和升级。
• 单一职责原则:不要存在多于一个导致类变更的原因，也就是说每个类应该实现单一的职责，否则就应该把类拆分。
• 里氏替换原则:任何基类可以出现的地方，子类一定可以出现。
• 依赖倒置原则:面向接口编程，依赖于抽象而不依赖于具体。写代码时用到具体类时，不与具体类交互，而与具体类的上层接口交互。
• 接口隔离原则:每个接口中不存在子类用不到却必须实现的方法，如果不然，就要将接口拆分。使用多个隔离的
• 迪米特法则:一个类对自己依赖的类知道的越少越好。无论被依赖的类多么复杂，都应该将逻辑封装在方法的内部，通过public方法提供给外部。这样当被依赖的类变化时，才能最小的影响该类。接口，比使用单个接口（多个接口方法集合到一个的接口）要好。
• 合成复用原则:尽量首先使用合成/聚合的方式，而不是使用继承。

创建型

工厂方法模式

定义：定义一个创建对象的接口，但让实现这里接口的类来决定实例化那个类，工厂方法让类的实例化推迟到子类中进行

优点

• 用户只需要关心所需要产品的工厂，无需关心创建细节
• 加入新产品符合开闭原则，提高扩展性

缺点

• 类的个数容易过多，增加复杂度
• 增加了系统的抽象性和理解难度

适用场景

• 创建对象需要大量重复的代码
• 应用层不依赖于产品类实例如何被创建、实现等细节
• 一个类通过其子类来指定创建那个对象

抽象工厂模式

定义：抽象工厂模式提供一个创建一系列相关或相互依赖对象的接口

优点

• 具体产品在应用层代码隔离，无需关心创建细节
• 将一个系列的产品族统一到一起创建

缺点

• 规定了所有可能被创建的产品集合，产品族中扩展新的产品困难，需要修改抽象工厂的接口
• 增加了系统的抽象性和理解难度

适用场景

• 应用层不依赖于产品类实例如何被创建、实现等细节
• 强调一系列相关的产品对象（属于同一产品族）一起使用创建对象需要大量重复代码
• 提供一个产品类的库，所有产品以同样的接口出现，从而使应用层依赖于具体实现

单例模式

注意：私有构造器、线程安全、延迟加载、序列化和反序列化安全、反射、cpu乱序执行优化

定义：保证一个类仅有一个实例，并提供一个全局访问点

优点

• 在内存里只有一个实例，减少了内存开销
• 可以避免对资源的多重占用
• 设置全局访问点，严格控制访问

缺点

• 没有接口、扩展困难

适用场景

• 想确保任何情况下都绝对只有一个实例

建造者模式

定义：将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示

优点

• 封装性好，创建和使用隔离
• 扩展性好、建造类之间独立、一定程度上解耦

缺点

• 会产生多余的Builder对象（使用Lombok的注解可以避免）
• 产品内部发生变化，建造者都要修改，成本较大（Lombok可以解决）

适用场景

• 如果一个对象有非常多的属性
• 想把复杂对象的创建和使用分离

原型模式

定义：指定原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象

优点

• 比直接new一个对象性能高
• 简化创建过程

缺点

• 必须配备克隆方法
• 对克隆复杂对象或对克隆出的对象进行复杂改造时，容易引入风险
• 深拷贝、浅拷贝要运用得当

适用场景

• 类初始化消耗较多资源
• new产生的一个对象需要非常繁琐的过程（数据准备、访问权限等）
• 构造函数比较复杂
• 循环体中产生大量对象时

行为型

适配器模式

定义：将一个类的接口转换成客户期望的另一个接口

优点

• 能提高类的透明性和复用，现有的类复用但不需要改变
• 目标类和适配器类解耦，提高程序扩展性
• 符合开闭原则

缺点

• 适配器编写过程需要全面考虑，可能会增加系统的复杂性
• 增加系统代码可读的难度

适用场景

• 已经存在的类，它的方法和需求不匹配时（方法结果相同或相似）
• 不是软件设计阶段考虑的设计模式，是随着软件维护，由于不同产品、不同厂家造成功能类似而接口不同情况下的解决方案

装饰器模式

定义：在不改变原有对象的基础之上，将功能附加到对象上，提供了比继承更有弹性的替代方案

优点

• 继承的有力补充，比继承灵活，不改变原有对象的情况下给一个对象扩展功能
• 通过使用不同装饰类以及这些装饰类的排列组合，可以实现不同效果
• 符合开闭原则

缺点

• 会出现更多的代码，更多的类，增加程序复杂性
• 动态装饰时，多层装饰时会更复杂

适用场景

• 扩展一个类的功能或者添加附加职责
• 动态的给一个对象添加功能，这些功能可以再动态的撤销

代理模式

定义：为其他对象提供一种代理，以控制对这个对象的访问

优点

• 代理模式能将代理对象与真实被调用的目标对象分离
• 一定程度上降低了系统的耦合度，扩展性好
• 保护目标对象
• 增强目标对象

缺点

• 代理模式会造成系统设计中类的数目增加
• 在应用层和目标对象增加一个代理对象，会造成请求处理速度变慢
• 增加系统的复杂度

适用场景

• 保护目标对象
• 增强目标对象

外观模式

定义：提供了一个统一的接口，用来访问子系统中的一群接口

优点

• 简化了调用过程，无需深入了解子系统，防止带来风险
• 减少系统依赖，松散耦合
• 更好的划分访问层次
• 符合迪米特法则，即最少知道原则

缺点

• 增加子系统、扩展子系统行为容易引入风险

适用场景

• 子系统越来越复杂，增加增加外观模式提供简单调用接口
• 构建多层系统结构，利用外观对象作为每层的入口，简化层间的调用

桥接模式

定义：将抽象部分与具体实现部分分离，使他们可以独立变化，通过组合的方式建立两个类之间联系，而不是继承

优点

• 分离抽象部分和具体实现部分
• 提高了系统的可扩展性
• 符合开闭原则
• 符合合成复用原则

缺点

• 增加了系统的理解与设计难度
• 需要正确地识别出系统中两个独立变化的维度

适用场景

• 抽象和具体之间增加更多的灵活性
• 一个类存在两个（或多个）独立变化的维度，且这两个（或多个）维度都需要独立进行扩展
• 不希望使用继承，或者因为多层继承导致系统类的个数剧增

组合模式

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

优点

• 清除地定义分层次的复杂对象，表示对象的全部或部分层次
• 让应用层忽略了层次的差异，方便对整个层次结构进行控制
• 简化应用层代码
• 符合开闭原则

缺点

• 限制类型时会比较复杂
• 使设计变得更加抽象

适用场景

• 希望应用层可以忽略组合对象与单个对象的差异时
• 处理一个树型结构时

享元模式

定义：提供了减少对象数量从而改善应用所需的对象结构的方式

优点

• 减少对象的创建，降低内存中对像的数量，降低系统的内存，提高效率
• 减少内存之外的其他资源占用

缺点

• 关注内/外部状态、关注线程安全问题
• 使系统、程序的逻辑复杂化

适用场景

• 常常应用于系统底层的开发，以便解决系统的性能问题
• 系统有大量相似对象、需要缓冲池的场景

结构型

策略模式

定义：定义了算法家族，分别封装起来，让它们之间可以相互替换，此模式让算法的变化不会影响到使用算法的用户

优点

• 开闭原则
• 避免使用多重条件转移语句
• 提高算法的保密性和安全性

缺点

• 应用层必须知道所有的策略类，并自行决定使用哪一个策略类
• 产生很多策略类

适用场景

• 系统有很多类，而他们的区别仅仅在于他们的行为不同
• 一个系统需要动态的在几种算法中选择一种

模板方法模式

定义：定义了一个算法的骨架，并允许子类为一个或多个步骤提供实现

优点

• 提高复用性
• 提高扩展性
• 符合开闭原则

缺点

• 类数目增加
• 增加了系统实现的复杂度
• 继承关系自身缺点，如果父类添加新的抽象方法，所有子类都要改一遍

适用场景

• 一次性实现一个算法的不可变的部分，并将可变的行为留给子类来实现
• 各子类中公共的行为被提取出来并集中到一个公共父类中，从而避免代码重复

观察者模式

定义：定义了对象之间的一对多依赖，让多个观察者对象同时监听某一个主题对象，当主题对象发生变化时，它的所有依赖者（观察者）都会收到通知并更新

优点

• 观察者和被观察者之间建立一个抽象的耦合
• 观察者模式支持广播通信

缺点

• 观察者之间有过多的细节依赖、提高时间消耗及程序复杂度
• 使用要得当，要避免循环调用

适用场景

• 关联行为场景，建立一套触发机制

迭代器模式

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

优点

• 分离了集合对象的遍历行为

缺点

• 类的个数成对增加

适用场景

• 访问一个集合对象的内容而无需暴露它的内部表示
• 为遍历不同的集合结构提供一个统一的接口

责任链模式

定义：为请求创建一个接收此次请求对象的链

优点

• 请求的发送者和接收者解耦
• 责任链可以动态组合

缺点

• 责任链太长或者处理时间过长，影响性能
• 责任链有可能过多

适用场景

• 一个请求的处理需要多个对象当中的一个或几个协作处理

命令模式

定义：将请求封装成对象，以便使用不同的请求

优点

• 降低耦合
• 容易扩展新命令或一组命令

缺点

• 命令的无限扩展会增加类的数量，提高系统实现复杂度

适用场景

• 请求调用者和请求接受者需要解耦，使调用者和接受者不直接交互
• 需要抽象出等待执行的行为

备忘录模式

定义：保存一个对象的某个状态，以便在适当的时候恢复对象

优点

• 为用户提供一种可恢复机制
• 存档信息的封装

缺点

• 资源占用

适用场景

• 保存及恢复数据相关业务场景
• 后悔的时候，即想恢复到之前的状态

状态模式

定义：允许一个对象在其内部状态改变时，改变它的行为

优点

• 将不同的状态隔离
• 把各种状态的转换逻辑，分布到State的子类中，减少相互间依赖
• 增加新的状态非常简单

缺点

• 状态多的业务场景导致类数目增加，系统变复杂

适用场景

• 一个对象存在多个状态（不同状态下行为不同），且状态可相互转换

访问者模式

定义：封装作用于某数据结构（如List/Set/Map等）中的各个元素的操作

优点

• 增加新的操作很容易，即增加一个新的访问者

缺点

• 增加新的数据结构困难
• 具体元素变更比较麻烦

适用场景

• 一个数据结构如（List/Set/Map等）包含很多类型对象
• 数据结构与数据操作分离

中介者模式

定义：定义一个封装一组对象如何交互的对象

优点

• 将一对多转化成了一对一，降低程序复杂度
• 类之间解耦

缺点

• 中介者过多导致系统复杂

适用场景

• 系统中对象之间存在复杂的引用关系，产生的相互依赖关系结构混乱且难以理解
• 交互的公共行为，如果需要改变行为则可以增加新的中介者类

解释器模式

定义：给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子

优点

• 语法由很多类表示，容易改变及扩展此“语言”

缺点

• 当语法规则数目太多时，增加了系统复杂度

适用场景

• 某个特定类型问题发生频率足够高