Unity 游戏框架搭建 2019 (五十一) MonoBehaviourSimplify 是框架？

本文主要是介绍Unity 游戏框架搭建 2019 (五十一) MonoBehaviourSimplify 是框架？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

在上一篇呢，我们的得到了目前库的一个分层图，如下:

而这个图中，把我们的库分成两个部分。一部分是框架，一部分是工具/库。

框架部分，只有一个 MonoBehaviourSimplify，而工具/库，则是除了 MonoBehaviourSimplify 以外的全部内容。

为什么 MonoBehaviourSimplify 是框架呢？

我们先来看看框架是什么？

框架：提供一个架构（文件结构、约定等等），你必须遵守它，只要你遵守，那剩下的就全部处理通用需求了。

这个定义呢是来自某个 JavaScript 大神书里写的。笔者非常认可这个说法。

那么 MonoBehaviourSimplify 为我们提供了怎样的架构？

只要我们的每个脚本都继承了 MonoBehaviourSimplify 就可以使用它的消息功能，并且它的消息功能非常方便，这个是利好的方面，我们想和某个脚本交互，不需要获得这个脚本的对象，而是两个脚本只要约定好注册的消息名就好了。

所以它的推荐使用方式是，继承。

其次，继承了之后，编译器会给你报错，因为要强制实现 OnBeforeDestroy 这个方法。那么这个就是多用户的约束，这部分其实是属于我们的约定部分。

框架和用户约定好了，如果想更爽地使用消息功能以及简化的 API，那么用户只能遵循它的用法，继承它，并重写 OnBeforeDestroy 方法。

那么说到这里，还没有提到架构两个字。

架构在哪里？

我们仔细回忆最初 MonoBehaviourSimplify 解决的是什么问题？

是解决脚本之间访问问题。

在使用 MonoBehaviourSimplify 之前，脚本之间交互的模拟图如下:

图中箭头的意思呢，是拥有脚本引用的意思，可以理解成成员变量，说耦合性非常高。

而使用了我们的 MonoBehaviourSimplify 之后，脚本之间的交互模拟图就会变成如下:

虽然我们的脚本还是与 MsgDispatcher 耦合了，不过情况好了很多，脚本之间就没有耦合了。
由于继承了 MonoBehaviourSimplify，在使用消息功能的时候压根感受不到 MsgDispatcher 存在。

而这就是 MonoBehaviourSimplify 提供的架构。

它提供了:

约定:
- 用户与框架之间的约定，用户想使用框架功能，就要遵循框架的使用规则。
规则:
- MonoBehaviourSimplify 的规则，就是要继承 MonoBehaviourSimplify，要覆写 OnBeforeDestroy。
共识:
- 用户与框架作者，都更推荐使用消息来处理脚本之间访问的问题。

而我们的 MonoBehaviourSimplify 除了提供了约定、规则、共识之外，还影响了脚本之间的交互结构。上边的两张图就是证明。

而在之前里说约定、规则、共识有什么用呢？

在这里笔者告诉大家。
架构的本质，就是约定、规则、共识。通过约定、规则、共识从而影响项目中任何东西的结构。比如项目目录规范（规则）导致了项目文件结构（编码规范）导致了代码结构，而主程与开发者的约定就会导致项目的模块结构以及团队结构等。总之，架构最终的目的，就是得到一个好的结构。好的目录结构，好的代码结构，好的程序结构，以及好的脚本之间交互所产生的结构，那么什么才算好呢？俗话说，就是弟兄们干活干得快干得好，项目跑得快跑得好，这就是好的架构。

扯得有点远了，总之，框架提供了架构，更准确地说，是一部分架构，而我们的 MonoBehaviourSimplify ，改善了脚本之间交互的问题，针对这个问题，提供了一个脚本之间的交互结构，也就是下图所示的结构。