其实ET主要是ECS的思路，不过OO的设计模式也可以借鉴一些好的。毕竟基于类。
ET将数据放在Entity，将方法放在Comoponent和System（扩展方法）里的思路对于热更来说真的是太方便了。
但是在开发过程中，还是有很多需求变更情况，（人员变更，需求变更，技术方案重构）等，这个时候团队保持思路一致，会带来很多好处，比如：交接容易，技术维护成本低等。
从今天起要将23个设计模式在ET里边的应用方法和思路抽出来，做一个系列，希望能够和大家多多交流，说的不对的地方请指正。
开发环境：
IDE：VS2017 pro
Unity：Unity 2019.4.29f1 (64-bit)
MongoDB：win32-x86_64-2008plus-ssl-3.4.9
OS：Windows10
UI：FairlyGUI 2021.3.1
先聊聊我理解的设计模式的几大原则：
- 单一职责
一个方法一次只做一件事情（做好积木模块，后面方便组合功能） - 开闭
需要支持在不修改历史的代码，流程的情况下添加新Feature后，不引入新的bug（在ET里边多见于System方法来扩展新功能，在时机项目中，很多新手团队出现的bug反复问题，来源于没有遵循这个原则） - 里氏替换
子类有一切父类的功能（但是在ECS里边，我觉得不太适用，毕竟都是通过组件来扩展功能） - 依赖倒置
抽象出流程，针对接口编程（例如：ET里边对流程的生命周期理解非常重要，OnStart，OnAwake，OnDestroy等待，需要针对这些“接口”来最好规划）
这个DIP原则，有一个比较好理解的例子就是：电脑的USB接口，只要满足USB的接口方法，任何电子设备都可以正常被识别和接入。放在ET框架理解：我们要做的框架就是主板，开出很多USB接口，其他人只要根据我定义的USB接口，那么硬盘，鼠标键盘，IO等外设，都可以接入了。从而实现拔插功能模块。从这个例子知道：我这里定义了一个抽象的USB接口，外设的功能千变万化，就是针对我定义的抽象接口编程，你实现什么功能就是什么外设。
同样ET框架也满足DIP原则，我这里提问：Game.Scene里边的接口有哪些，是怎么实现的？ - 接口隔离
不要把所有的接口方法都设置为必须实现的，这点好理解，比如我写一个网络接口，你没必要让我实现本地存储的接口。 - 最少知识
我的理解是：高内聚低耦合，不要单例满天飞，否则后面没法维护了。必须减少类模块之间的耦合。通过OB模式，等模式来做解耦。
这个模式也是主程们最喜欢的模式，重构大法，只有深刻理解这个模式，才能往主程走进一步。 - 少继承多组合
我的直观感受，如果违反了这个原则，那么基于OO编程的最可怕的就在于多重继承，一旦缺少规划和维护，时间一长就会变成一个特别大而全的类了。
还有一些原则，我的理解之所以叫原则，那就是独孤九剑的剑招，只可意会不可言传，没办法说的非常细致，只能针对具体问题具体分析，也不能为了模式而模式。只有恰到好处的精妙设计，不要东施效颦的拙略模仿。这一拳二十年的功夫，不是一朝一夕能搞出来的。
针对这些原则和经验，国外的GOF，提出了的23种设计模式，基本上可以分为三大类：
- 生成模式：产生对象的过程和方式 5个
工厂，抽象工厂，单例，构造，原则
- 结构模式：对象之间组合的生命周期 7个
适配器，外观，桥接，装饰，代理，组合，享元
- 行为模式：数据交互或者互动的方式 11个
模板，策略，命令，中介，观察，迭代，访问，责任链，备忘录，状态，解析器
当然ET里边也不是包含了所有的设计模式，里边的一些常用的就几种。
为啥要学这个：记住 ~ 不要开起袖子就撸，否则永远是底层码农。你写的代码，不要一上来就被主程重构了。
