- 使用在设计之前建模使用
- 用来干什么：1. 把类结构描述出来 2.把类与类之间的关系关联起来
- 类之间的关系：
- 继承: 带空心三角形实线。箭头表示继承自
- 关联: 一个类和另一个类有关系，用带箭头或不带箭头的实现连接，一般表示类内有其他类的成员变量，箭头表示包含有
- 单向关联：
- 双向关联：互有成员
- 自关联：链表
- 组合:也是成员，但是在析构的时候会把成员都析构掉，实心菱形直线表示。比较严谨，关系不松散。
- 聚合:表示类和类之间的从属关系，即整体和部分，用空心菱形的直线表示，如汽车和引擎，松散结构，子部分可以单独拿出来。一般就是类内有其他类的成员，且析构时不这些成员。即这些是可以单独存在的。箭头指向整体。
- 依赖：排除法，一般是函数参数、局部变量。带箭头虚线，指向被依赖对象
- 备注：
- 虚函数用斜体，纯虚函数=0
- 单一职责原则：类应该是单一职责的，功能单一，不应该是某些事物的集合，容易维护，不冗余，臃肿，设计的时候尽可能单一，不要想万能类，万能函数。
- 开放封闭原则：单一职责的延续，对扩展是开放的，类外可以扩展新的类来处理当前的类；对修改是封闭的，要保证自己的类是单一职责。避免这个类已经被使用了，修改易出错。
- 细节：开放封闭原则，对已经封装好的类，添加新需求应该新建类，而非修改原来的类。这里需要在设计前预留接口，通过多态的方式。其实就是先定义好基类，然后预留接口，不同场景通过派生实现接口，新场景派生新类新接口，不去修改原来的类。
- 依赖转换原则：上层应用。即业务实现，不应该依赖底层模块，即底层接口，比如封装好的API，动态库等。最好在中间加一层抽象，比如业务需要请求mysqlAPI，那就应该先封装一层sqlAPI类，都是虚函数，然后通过这个抽象类的派生类实现这些接口去访问。
- 作用：解耦、减少代码重复，当对象需要改变时，调用者代码不需要变
- 解耦：直接new调用者需要知道每个需要new的类的关系，但如果把构造方式交给工厂，则只需要跟工厂说需要哪个对象即可
- 减少代码重复：如构造一个对象苹果，需要树、阳光等，且构造其他水果也需要，那么这里其实很多重复代码，这种情况应该用继承来解决吧
- 创建对象：
- 新建一个工厂类，负责生产对象，简单工厂只需要一个
- 提供公共函数，由该函数负责生产对象，即工厂函数
- 创建工厂对象制定类型调用生产即可
- 分类
- 简单工厂模式：只有一个工厂，提供create方法，直接用switch分之来解决，适用于简单对象
- 缺点：
- 违背单一职责：每当生产过程需要修改都需要修改工厂类
- 违背开闭原则：新增产品需要新增工厂类分支，而非新增类解决。
- UML：1676815184394.jpg
- 缺点：
- 工厂模式：每个产品都有对应的专属工厂，工厂是一个抽象类，如接口类，不同的产品有自己的工厂类继承自基类工厂，实现create方法即可。调用者调用不同的工厂类的create方法。感觉可以优化下用register注册到一个map里面，然后还是用名字来调用工厂的create方法返回对象。
需要创建N个工厂类，适用于复杂对象
- 好处：解决了简单工厂的问题，需要修改不同产品的生产流程只需要修改对应的类，需要新增产品也只需要继承该工厂的create方法然后实现一个类
- 使用场景：如果是只有几个对象需要生产则直接使用简单工厂即可。如果是考虑后续扩展及维护以及遵循设计模式原则，则直接用工厂模式
- 抽象工厂类，派生每个产品的工厂类，每个工厂类实现create方法新建每个产品，产品也是搞一个抽象基类
- 抽象工厂模式：需要创建N个工厂类,适用于复杂对象，生产产品更复杂。优化工厂模式，对产品进行进一步抽象，如家具需要抽象为不同风格，沙发，桌子，椅子，中式西式。
- 场景：产品种类繁多，且产品可由不同的零部件组成，比如说抽象工厂类，中式风格工厂类，西式风格工厂类，每个风格下面需要有桌子，椅子，沙发等。桌子椅子沙发也是一个抽象基类，下面如沙发可以有中式木沙发，西式软皮沙发等。然如中式风格家具需要有中式木沙发，红木床等组合，调用者调用中式风格工厂类，create方法，返回一个中式风格家具基类，家具基类可以提供属性方法用来知道当前的组合情况是怎样的。这里家具也是一个基类，中式风格家具是一个子类，跟桌子、椅子、沙发、床等是一个组合关系
- ps：组合和聚合的区别是在析构的时候要不要对成员进行西沟。
- 简单工厂模式：只有一个工厂，提供create方法，直接用switch分之来解决，适用于简单对象