我们花了 5 篇文章学习了消息机制的方方面面。并且完成了一个简易消息机制，之后集成到了我们的 MonoBehaviourSimplify 里。
现在 MonoBehaviourSimplify 有一点框架的感觉了。因为 MonoBehaviourSimplify 在提供消息功能的同时，决定了项目脚本中的交互方式。而目前的这套结构，足够用它来完成一个比较小的项目了。
消息机制是笔者在接触单例之后，第二次被震撼到的设计模式（观察者模式/发布者订阅者模式）。而笔者在初学的时候，还不太敢去设计 MonoBehaviourSimplify 这样的基类，因为当时总觉得自己对 MonoBehaviour 生命周期理解得不够透彻。但是，笔者在使用消息机制的时候遇到了很多问题，比如之前提到的，总是忘记注销消息，从而导致游戏闪退等各种奇怪的 bug，随着 bug 遇到得多了，就越来越意识到自动注销消息的重要性，而自动注销消息最好的方式就是通过继承基类的方式。所以就冒着风险被迫着就去写了这么一个类，这个类以前的名字叫做 QNode 也就是我们今天 MonoBehaviourSimplify 的前身，直到现在为止，QFramework 的核心还是通过 QNode 演变过来的类，现在叫做 QMonoBehaviour。
而在当时通过设计这么一个基类之后，笔者就对设计父类这种形式有了很大的信心，所以就只要能加到 MonoBehaviourSipmlify 的东西就全部加进去了，一直这样下去，理论上这样也不会发生问题，但是后来又找到了更好的方式，学习了更好的方式之后呢，就可以分辨出来哪个适合继承，哪个适合用方法独立实现，而哪个适合做成更复杂的系统。不过目前的这套结构，如果各位学到这里也没有太大的问题，已经可以拿去做项目了。
但是如果想做出更好的库和框架，那就最好认真看完这个专栏的文章。因为这是笔者三年框架思考的浓缩版。
而到目前为止，我们可以画出来一个框架的结构图了。
如下所示:
虽然东西不多，但是至少目前的我们的库可以叫做框架了。
到这里呢，我们还没有去讲框架、架构、库这些东西，现在正是讲这些概念的最好时机，所以从下一篇开始，我们会慢慢接触这些概念。
在上一篇呢，我们的得到了目前库的一个分层图，如下:
而这个图中，把我们的库分成两个部分。一部分是框架，一部分是工具/库。
框架部分，只有一个 MonoBehaviourSimplify，而工具/库，则是除了 MonoBehaviourSimplify 以外的全部内容。
为什么 MonoBehaviourSimplify 是框架呢？
我们先来看看框架是什么？
> 框架：提供一个架构（文件结构、约定等等），你必须遵守它，只要你遵守，那剩下的就全部处理通用需求了。
这个定义呢是来自某个 JavaScript 大神书里写的。笔者非常认可这个说法。
那么 MonoBehaviourSimplify 为我们提供了怎样的架构？
只要我们的每个脚本都继承了 MonoBehaviourSimplify 就可以使用它的消息功能，并且它的消息功能非常方便，这个是利好的方面，我们想和某个脚本交互，不需要获得这个脚本的对象，而是两个脚本只要约定好注册的消息名就好了。
所以它的推荐使用方式是，继承。
其次，继承了之后，编译器会给你报错，因为要强制实现 OnBeforeDestroy 这个方法。那么这个就是多用户的约束，这部分其实是属于我们的约定部分。
框架和用户约定好了，如果想更爽地使用 消息功能以及简化的 API，那么用户只能遵循它的用法，继承它，并重写 OnBeforeDestroy 方法。
那么说到这里，还没有提到架构两个字。
架构在哪里？
我们仔细回忆最初 MonoBehaviourSimplify 解决的是什么问题？
是解决脚本之间访问问题。
在使用 MonoBehaviourSimplify 之前，脚本之间交互的模拟图如下:
图中箭头的意思呢，是拥有脚本引用的意思，可以理解成成员变量，说耦合性非常高。
而使用了 我们的 MonoBehaviourSimplify 之后，脚本之间的交互模拟图就会变成如下:
虽然我们的脚本还是与 MsgDispatcher 耦合了，不过情况好了很多，脚本之间就没有耦合了。
由于继承了 MonoBehaviourSimplify，在使用消息功能的时候压根感受不到 MsgDispatcher 存在。
而这就是 MonoBehaviourSimplify 提供的架构。
它提供了:
* 约定:
* 用户与框架之间的约定，用户想使用框架功能，就要遵循框架的使用规则。
* 规则:
* MonoBehaviourSimplify 的规则，就是要继承 MonoBehaviourSimplify，要覆写 OnBeforeDestroy。
* 共识:
* 用户与框架作者，都更推荐使用消息来处理脚本之间访问的问题。
而我们的 MonoBehaviourSimplify 除了提供了约定、规则、共识之外，还影响了脚本之间的交互结构。上边的两张图就是证明。
而在之前里说约定、规则、共识有什么用呢？
在这里笔者告诉大家。
架构的本质，就是约定、规则、共识。通过约定、规则、共识从而影响项目中任何东西的结构。比如项目目录规范（规则）导致了项目文件结构（编码规范）导致了代码结构，而主程与开发者的约定就会导致项目的模块结构以及团队结构等。总之，架构最终的目的，就是得到一个好的结构。好的目录结构，好的代码结构，好的程序结构，以及好的脚本之间交互所产生的结构，那么什么才算好呢？俗话说，就是弟兄们干活干得快干得好，项目跑得快跑得好，这就是好的架构。
扯得有点远了，总之，框架提供了架构，更准确地说，是一部分架构，而我们的 MonoBehaviourSimplify ，改善了脚本之间交互的问题，针对这个问题，提供了一个脚本之间的交互结构，也就是下图所示的结构。
这就是我们库当中，属于框架的部分。
OK，我们最后再回顾一下，什么是框架:
> 框架：提供一个架构（文件结构、约定等等），你必须遵守它，只要你遵守，那剩下的就全部处理通用需求了。
从这一点去考虑，我们的 MonoBehaviourSimplify 是不是框架呢？
转载请注明地址：凉鞋的笔记：[liangxiegame.com](http://liangxiegame.com)
## 更多内容
* QFramework 地址：[https://github.com/liangxiegame/QFramework](https://github.com/liangxiegame/QFramework)
* QQ 交流群：[623597263](http://shang.qq.com/wpa/qunwpa?idkey=706b8eef0fff3fe4be9ce27c8702ad7d8cc1bceabe3b7c0430ec9559b3a9ce66)
* **Unity 进阶小班**：
* 主要训练内容：
* 框架搭建训练（第一年）
* 跟着案例学 Shader（第一年）
* 副业的孵化（第二年、第三年）
* 权益、授课形式等具体详情请查看[《小班产品手册》](https://liangxiegame.com/master/intro)：https://liangxiegame.com/master/intro
* 关注公众号：liangxiegame 获取第一时间更新通知及更多的免费内容。
