Unity 游戏框架搭建 2019 (五十、五十一) 消息机制小结&MonoBehaviourSimplify 是框架?

我们花了 5 篇文章学习了消息机制的方方面面。并且完成了一个简易消息机制,之后集成到了我们的 MonoBehaviourSimplify 里。

现在 MonoBehaviourSimplify 有一点框架的感觉了。因为 MonoBehaviourSimplify 在提供消息功能的同时,决定了项目脚本中的交互方式。而目前的这套结构,足够用它来完成一个比较小的项目了。

消息机制是笔者在接触单例之后,第二次被震撼到的设计模式(观察者模式/发布者订阅者模式)。而笔者在初学的时候,还不太敢去设计 MonoBehaviourSimplify 这样的基类,因为当时总觉得自己对 MonoBehaviour 生命周期理解得不够透彻。但是,笔者在使用消息机制的时候遇到了很多问题,比如之前提到的,总是忘记注销消息,从而导致游戏闪退等各种奇怪的 bug,随着 bug 遇到得多了,就越来越意识到自动注销消息的重要性,而自动注销消息最好的方式就是通过继承基类的方式。所以就冒着风险被迫着就去写了这么一个类,这个类以前的名字叫做 QNode 也就是我们今天 MonoBehaviourSimplify 的前身,直到现在为止,QFramework 的核心还是通过 QNode 演变过来的类,现在叫做 QMonoBehaviour。

而在当时通过设计这么一个基类之后,笔者就对设计父类这种形式有了很大的信心,所以就只要能加到 MonoBehaviourSipmlify 的东西就全部加进去了,一直这样下去,理论上这样也不会发生问题,但是后来又找到了更好的方式,学习了更好的方式之后呢,就可以分辨出来哪个适合继承,哪个适合用方法独立实现,而哪个适合做成更复杂的系统。不过目前的这套结构,如果各位学到这里也没有太大的问题,已经可以拿去做项目了。

但是如果想做出更好的库和框架,那就最好认真看完这个专栏的文章。因为这是笔者三年框架思考的浓缩版。

而到目前为止,我们可以画出来一个框架的结构图了。
如下所示:
006tNc79gy1fzft76krotj30w20ey3zt.jpg

虽然东西不多,但是至少目前的我们的库可以叫做框架了。

到这里呢,我们还没有去讲框架、架构、库这些东西,现在正是讲这些概念的最好时机,所以从下一篇开始,我们会慢慢接触这些概念。

在上一篇呢,我们的得到了目前库的一个分层图,如下:
006tNc79gy1fzft7y8unhj30w20ey3zt.jpg

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

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

为什么 MonoBehaviourSimplify 是框架呢?

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

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

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

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

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

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

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

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

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

架构在哪里?

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

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

在使用 MonoBehaviourSimplify 之前,脚本之间交互的模拟图如下:
006tNc79gy1fzft84no0tj30q00j2aat.jpg

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

而使用了 我们的 MonoBehaviourSimplify 之后,脚本之间的交互模拟图就会变成如下:
006tNc79gy1fzft8avq62j30zq0ggta9.jpg
虽然我们的脚本还是与 MsgDispatcher 耦合了,不过情况好了很多,脚本之间就没有耦合了。
由于继承了 MonoBehaviourSimplify,在使用消息功能的时候压根感受不到 MsgDispatcher 存在。

而这就是 MonoBehaviourSimplify 提供的架构。

它提供了:

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

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

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

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

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

这就是我们库当中,属于框架的部分。

OK,我们最后再回顾一下,什么是框架:

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

从这一点去考虑,我们的 MonoBehaviourSimplify 是不是框架呢?

转载请注明地址:凉鞋的笔记:liangxiegame.com

更多内容

posted @ 2020-05-29 14:18  凉鞋的笔记  阅读(204)  评论(1编辑  收藏