一.外观模式
定义：为子系统定义一组统一的接口，通过一个FacadeManager来将调用暴露给外面，而实现在各个子系统内部实现，各个子系统互不影响，外部也无法直接调用子系统的接口，保证安全性的同时，也保证了子系统的扩展性和独立性。
应用：（神兵系统），适用于设计一个系统的结构时，将大功能拆分成几个小系统，分别来实现内部接口的编写，供外部界面使用。
二.观察者模式(数据结构源码)
定义：一个事件发生变化时，依赖他的对象自动被提醒
应用：（消息监听系统）
Dictionary
tips：字典中保存了Action即特殊类型的委托，那如果外部的Action中的变量被销毁了，会怎么样
List.Add在扩容时保证初始容量为4，且以二倍方式扩容，如果二倍扩容后的容量仍然小于需要的值min，直接将容量设置为min即所需的大小，List是引用类型，
三.状态模式（behaviortree， 蓝图）
定义：不用太多的if else而是用状态模式将每种情况或者行为独立定义一个状态，只负责自己的内部实现，优点是降低耦合性和易读性，缺点是会定义很多的类
应用：节点式的行为，蓝图的设计方法
四.单例模式（线程）
定义：代码中只存在一个实例，避免重复创建一个实例（通常懒汉式，第一次用到的时候才创建）
应用：管理器，场景中只需要存在一个的管理类
tips：
1.继承哪个？
（1）无需放在场景中，继承自new即可 public class Singtlon
（2）放在场景中，可以动态添加脚本
public class SingletonCom
where T : Component
（3）错误的写法
public class SingtlonMB
想要放在场景中成为实例必须继承mono，但unity是组件式编程，所有继承自monobehaviour的脚本都要绑定到游戏对象（object）上才能运行，需要用GetComponet<>函数来使其实例化，而不能用new（new是实例化不了此对象的），强行用的话运行时会弹出警告，而且new出来的对象会为NULL。只有不是继承自monobehaviour类的才能用new实例化
2.线程安全和锁的问题
public static T Instance
{
get
{
lock (_lock)
{
if (_instance == null)
_instance = new T();
return _instance;
}
}
}
锁住lock大括号里的语句块，执行期间其他线程不能访问_lock和lock锁住的代码块，执行完后别的线程才可以访问，保证线程安全
五.工厂方法模式
定义：父类不决定实现，而由子类自己决定实现
应用：ui管理，父类定义interface和抽象方法，子类实现具体的方法
tips：abstract方法没有实现，virtual方法有实现，c#中可用interface来规范行为，抽象类只能被继承不能被实例化，同样子类必须实现抽象方法
也就是定义一个abstract类，里面既可以有抽象方法也可以有虚方法，也可以有实际方法，实际方法会被所有的子类调用，虚方法子类可以选择重写，抽象方法子类必须实现
六.责任链模式
定义：流水线式的链式结构，各个节点负各自的内容，从上一阶段接受数据传到下一个阶段，将处理过程分为多个部分，减少请求者和处理者之间的耦合度
应用：流水线式的模式或者应用需求，类似于审批之类的，可以用责任链完成，降低耦合度，各个节点只关注自己的
七.模板方法模式
定义：将一个流水线的一个环节开放出来供修改，只提供进入此阶段的数据，并传出处理后的数据，开发者只关注此阶段，保证其他阶段的安全性
应用：shader的顶点，片元着色器，作为渲染流水线的一部分可以被修改，
八.享元模式（hash表）
定义：使用共享对象可有效地支持大量的细粒度的对象，具体就是当一大堆对象不同的地方只有很少的地方的时候，使用享元模式来缓存对象，
应用：string缓存，对象池等
tips：首次创建存储到hash表，再次创建时先查询是否已经存在，是的话就使用当前缓存的对象
九.脏标记模式
总是在大佬的代码里看到dirty字段，不清楚别人代码的逻辑，但觉得这个字段一定有他好用的地方，所以学习了下，原来是一种设计模式，Mark下。
定义：将工作推迟到必要时进行而避免不必要的工作
理解：怎么具体理解这个事情呢，最常用的应用场景是涉及到父子层级变换，像是坐标变换中的父物体坐标变化的话，子物体同样要跟着变化，通用的做法是每帧遍历根节点的所有子节点并进行坐标变换，而这会有个问题，假如我们的很多物体的位置并没有发生变化呢，例如场景中的很多静态的物体。此处就可以用到脏标记模式来优化，为每个节点标记一个dirty字段，如果为true说明上层位置发生了变化，需要重新计算当前节点的位置，如果为false说明上层的位置无变化，那么当前节点不需要发生变化。于此同时，需要开辟一定的内存空间来存储当前的所有位置，也就是进行缓存，如果不需要更新直接使用缓存的位置。宏观来看也是一种通过空间换取时间的做法。
应用：（1）涉及到层级变换的地方，尤其在逻辑需要每帧update，这样做会省去很大的开销。
（2）文档的实时保存，常用的编辑器在不停的修改内容时，如果实时保存会开销太大，而不保存到用户退出再保存则可能发生意外而无法保存，权衡的方法也是保留一份缓存即副本，间隔一定的时间保存一下，权衡好时间和空间的问题而使得问题得到最优解
tips：由此反思，当作为客户端和服务器通信的时候，很多时候数据结构里面的大部分数据可能不会发生变化，如果数据结构拥有层级关系，是不是也可以用这个模式进行优化，而不是无脑的每次把客户端收到的数据重刷一遍
十.策略模式
A和B（B是一个大类，B可能有很多种），A去和B交互，对于不同的B，A的执行或者B的执行可能不同、
笨比做法：容易想到的笨比做法，就是A每次发出一个action去区分B的类型，然后根据B的类型去做出不同的行为，A的Interaction函数避免不了要写一个switch或者if else函数来区分不同的B类型，这就会导致，A这个函数过大，A和B耦合性太高，每次新加一个B类型，A的函数就要多写一段代码，我增加B凭什么每次都要去改A呢？，确实很笨比
设计模式：声明一个接口函数algorithmInterface(A a)，参数为A，每个B都要实现这个接口函数的重写，来自己实现自己的策略，这个的好处就是A不用关心有多少个B，而B增加类型的时候也只需要关心自己的策略方法，而不会对其他B和A产生影响
十一.模板方法模式
定义一个操作中算法的框架，而将一些步骤延迟到子类中，使得子类可以不改变算法的结构即可重定义该算法中的某些特定步骤。
理解：子类比较多而又有很多方法和行为相同时，将相同的部分抽离到父类，子类做具体细节的有区别的实现。
十二.适配器模式
将两个模块调用中间加一个适配器类，使得两部分虽然可以交互，但是保证其密封性，SDK的接入多采取这种方式，尽量让业务逻辑不要直接调用一些外部SDK提供的方法，而通过适配器调用，缺点是：使用时要注意适配器的数量，过多的话会造成系统适配器过多，凌乱，且难以维护
十三.装饰器模式
动态地将责任附加到对象上。若要扩展功能，装饰者提供了比继承更有弹性的替代方案
理解：当需求变化时，你可能需要增加子类来扩展，但是子类数量会愈发庞大，而且你会发现其实很多功能和数据都是重复的，可能你后续扩展的子类中都必须要包含初始类中的特定数据和方法，这样一来，扩展麻烦，类也会很多。装饰器模式就是说将这个扩展或者说增加的功能方法抽象出来，让他作为最开始类的一个装饰，使得扩展方便，改动也会很小。