深入浅出制作全自动Mud机器人-全局单例

[jarlyyn]

单例模式，是设计模式的一种。它是一种创建型设计模式，它的核心目标是确保一个类只有一个实例，并提供一个全局访问点来获取这个唯一的实例。

听着很牛吧？别管这个，这是被强OOP祸害的语言的鬼话。

单例模式本质就是，全局变量。

好了，使用lua的同学们放下手。全局变量不是你不用加local 来限制使用作用范围的意思。

单例可以通过全局变量来实现，但它强调的还是独一无二性，在英语里要加上the 定冠词那种(嗯，就是黑客帝国的the one)。

说明是一个特殊，独一无二的个体。

在代码开发中，很常见的一种模式是，将整个程序的功能，抽象成一个Applcation,然后建立一个全局单例 Applcation:Instance 来进行代码的开发。

在Javascript的管理，就是建立一个全局的app对象，Lua作为脚本语言，也可以适用这套模式。

那么，问题来了，我们为什么要用这个全局变量(单例)呢？

限制其他全局变量使用。

使用全局变量，就是能方便的在任何代码里进行数据分享/互相调用。

有需要就开一个全局变量，看似开发能快很多，但很快就会让代码失去可维护性，随便动一个变量都生怕整个程序崩了。

当我们有一个特殊的全局变量后，很自然的，我们需要调用的东西都会从这个全局变量(单例上找)，不应该再开全局变量。

从这个角度来说，这个单例，就是我们整个机器人的the one

定义应用程序的根(root)

我看过很多全自动机器人代码。有一些，嗯，怎么说呢，让我感觉很乱，无从下手。

代码都是一个个平级的.lua/.js文件，互相之前会相互应用，要看很久才能推测出大概的功能划分。

按数据结构的说法，这些机器人的代码互相之间的关系是一个图(Graph),两两之间都可能有关联，很自由，很强大。

但对于我等普通人来说，难以驾驭。

相对而言，以我的能力，更能处理以数据结构的 树(tree) 的形式来组织的代码。

即从一个根room开始，不停分支，对应着一个一个的节点，和树杈一样。

我们在使用电脑时，最常见的树结构就是目录树，通过一个一个目录来对文件进行组织。

只有了一个固定的根，我们才能很容易的定义文件的代码的结构和组织结构。

给代码一个独一无二的挂载点。

上一个部分讲到了目录这个例子，那么我们扯远点说说Linux的文件管理。

linux下，讲究万物皆文件。不管你是设备，文件系统，文件，目录，都可以用mount的方式挂在到相对于根(root)目录的指定位置下。

那么，当我们使用单例App时，其实也是一样，把我们的代码/对外的结构，添加到单例和他的自元素上，就相当于做一个mount操作。

这时，每个挂载上去的代码，都成了一个单例(单例中的特定部分)，都能很方便的找到。

在一般情况下，可能这个优势还不明显。

在javascript和lua中弱类型的脚本语言中，很难精确的定位到一个代码的位置。

那么，你觉得在你的代码中，是找到一个较 room的变量在哪里定义使用方便，还是一个App.Core.Map.Room 方便呢？

代码分组

还是文件目录的例子。

我们一般会怎么组织文件？

先把全放桌面的豪放流请下去。最常见的，其实是是按文件的用途或者特点，分为 文档，视频，照片，作业，学习资料什么的。

同样，既然我们把单例作为文件数来使用，我们也可以把代码和数据进行分区。

比如，主业务逻辑可以放在App.Core.XXX下，代码可以放在App.Data.XXX下，工具函数可以放在App.Utils.xxx下

这样在写代码时，可以一目了然，方便理解和组织。

总结

对于代码来说，全局变量(单例)是必不可少的，但是太多的单例会让代码复杂度指数上升。通过定义一个合适的根单例，我们能更好的组织代码，提可高维护性。