单例模式，是设计模式的一种。它是一种创建型设计模式，它的核心目标是确保一个类只有一个实例，并提供一个全局访问点来获取这个唯一的实例。 听着很牛吧？别管这个，这是被强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下 这样在写代码时，可以一目了然，方便理解和组织。 总结 对于代码来说，全局变量(单例)是必不可少的，但是太多的单例会让代码复杂度指数上升。通过定义一个合适的根单例，我们能更好的组织代码，提可高维护性。

在全自动Mud机器人开发，以及长期的运维更新时，我觉得引入组件化是一件非常重要的底层架构。 组件化，看起来是一个和模块化接近的概念。但本质完全不同。 在我眼里，模块化是将相关的代码进行组织和封装，对外提供统一接口的一种代码组织形式。 组件化的确要依赖于模块化是实现功能。但更重要的是，组件化的目标是 可替代可废弃性。 随着Mud的更新，代码不应该进行大幅度的调整，还是废弃部分组件，新建部分组件，调整部分组件。这样，机器可以先将重点组件进行调整，然后临时禁用不重要的组件，甚至部分影响不大的组件带病工作，实现机器的边开发边运行。 既将代码根据易变程度分为不同的组织，确保核心代码的稳定性，然后组件中可以用各种快速/不健全/临时性的机制确保特殊状态下机器的可用性，以及确保机器处于一种可以从小到大，逐渐成长的状态。 为了实现这个目的，组件化需要实现的功能是 组件标准化 同一类的组件，应该有相同的接口和核心代码进行交互。这样，核心代码才能在调整主键时不需要关注细节和深入。 以我的newhelljs为例，使用了多种组件 角色准备阶段的提案组件 通过通用的Submit参数，实现判断是否进入某个准备阶段 任务本身的[Quest组件](https://github.com/hellclient-scripts/newhelljs/blob/main/script/src/core/quests.js 通过Ready参数，Cooldown属性，OnHUD/OnSummary|OnReport等接口，实现了人物与核心代码的隔离 配置的Condition组件 使得是否接任务/是否使用某个技能等等，都与核心代码无关，完全通过定义新的Condition实现。 很明显，组件标准化和能区分组件代码和核心代码的前提。如果不对组件进行标准化，则可扩展性可维护性也成了无根之水。 控制反转 控制反转(IOC)是一个常见的程序开发思路。 所谓的反转，就是将** 主程序创建类后，初始化类** 反转为 ** 主程序只负责创建类，类自行初始化) 实现了控制反转后，才能实现组件的封装，将组件与核心代码分离。 核心代码只负责两件事情: 如果你随手搜索一下,可能会发现一大堆依赖注入，工厂模式什么的复杂东西。 不用管那些，那些主要是对强OOP，静态编译的Java强调的东西。 对于js/lua的实现，参考我上面的例子中，都会传入一个函数作为参数就可以了。 把初始化函数放在组件的制定位置，核心代码创建组件后，把配置作为参数带入初始化函数就可以了。 这里说的控制反转，只是提醒一下，不要在核心端去设置组件，让组件自包含。 全局注册 全局注册很简单，就是建立一个全局的object/table变量,给每一个组件起一个唯一的字符串主键，将组件或者组件的生成函数都放在里面就行。 全局注册的目的是 在进行组件的替换/更新甚至顺序调整时，无需调整核心代码，只需要调整某个配置即可。 通过同一的调用方式，确保不会有其他位置的代码来直接调用组件内的代码，避免组件修改时出现全局问题。 方便的管理方式，能很容易的明白有多少个可用模块，不用去各个代码目录里寻找。 使用全局注册要注意的点是 只通过 注册的表 与组件交互，不建立直接处理的代码 在多个组件交互时，可以通过给组件加接口/全局事件/核心组里注册特殊毁掉的方式来处理。 重要的点 使用组件模式，其实是按照我们最初的目的来使用，也就是 将代码分为干净的核心代码，和脏(与业务更接近)的组件代码。确保代码指令控制在一个基本的可用度上。 通过配置，设置，能动态的调整激活的模块，实现更复杂的功能。 技术只是手段，代码如何处理，不一定要强求某个模式，还是为了实际目的服务。

在写gui程序时，我整理了一套代码组织方式 参看 HellMapManager项目就是按这个架构来组织的。 对于Mud机器人，我觉得这个组织形式也适用。当然，由于主要业务不同，住址形式也会不同。我只是将所有的代码根据对应的层次打个标签，避免不同层级的代码过于混淆。 UI 交互层 这个完全绑定于客户端的实现，在Mud机器人里也相对不重要，可以和Service层混在一起 Service 服务器层。从字面意义上来说，就是为最终用户提供的功能的封装层。UI交互的内容最终绑定到服务层上。最大的用途是防止用户UI直接操作到业务层，做封装和拦截，以及抽象。 Core 核心(业务) 层。对于Mud机器人来说，绝大部分的代码都是核心层。所以实际写机器人的时候Core肯定还要做细分，比如底层核心和任务模块。 Helper 辅助类，业务层和数据层直接的纽带，将数据的细节对业务做一定的封闭。 Adapters 适配器层 抽象底层交互。对于Mud机器人来说，就是将客户端的触发/别名/计时器做一个抽象，以及对应的事件Event框架。引入这个层的话能提升机器人可迁移性和做测试的可能。 Model 模型 在各个业务层中共同的数据结构。在Mud中比如房间，玩家，道具等等。 utils 工具层。比如中文转数字，格式化文字等纯与业务无关的，全局都可能使用的代码

在引言中，我们提到过，制作全自动机器人的一个重要课题是 怎么才能让循环更稳定，控制更多的资源和状态？ 那么，提升稳定性的一个重要的工作，就是当服务(机器人)发生意外时，能及时的通知运维(开发者/用户)查看问题，进行操作。 就是当机器停顿，无法继续，甚至ID死亡时，以方便的手段通知用户，记录问题现场，恢复程序执行。 这也是一个标准的运维工作。 所以我建议参考现在主流的运维工作流程。 邮件形式 Hellclient最早是支持嵌入STMP信息，提供了内建方法可以发送电子邮件。 但在实际使用时，基本处于被废弃状态。 因为现在主流的运维通知终端是手机，安卓或者iOS。 邮件通知在手机上面临了一下问题 手机设备上，邮件客户端无法保证后台常驻，实时性往往有很大问题。 邮件客户端又有各种实现，对于链接的处理形式不同，无法保证唤起我的APP端。 邮件的安全级别很高，所有各个邮件服务器的安全设置很复杂，对用户并不友好。 通知服务 我的Hellclient UI项目曾经实通过腾讯推送实现过原生的推送功能。 但现在这个功能已经被废弃了。 通知服务会涉及到几个难点 用户识别问题。安卓客户端还能自行申请推送服务，iOS不现实，发布时就绑定应用ID。 保活问题。对于国内环境，国产安卓是绕不过去的槛。各种手机的保护和续航是很麻烦的点，只是做一个mud相关的app没法投入这么多精力去处理 这写严重的问题随着新的方案出现，对于Hellclient UI项目属于验证的得不偿失，所以废弃了这个功能。 Webhook 目前的运维主流的通知手段其实还是webhook的形式。 就是在各种工作流软件中，会提供一个标准的，地址带身份验证token的http接口。 主要对这个接口发送特殊格式的内容，就会通过服务器向对应的手机APP发送一条通知。 处于这个通知的专用型，一般都能确保拉起手机中注册过的APP直接处理。 可以说完美的适合了Mud机器人，作为一个标准意义上的服务的运维要求。 而且webhook形式的要求最低，基本不需要客户端做特殊支持，只要提供标准的HTTP接口和JSON支持就可以了。 国内比较常见的Webhook供应商为 企业微信 钉钉 飞书 国外知名的有 Slack 根据我自己的使用体验和经验，我的机器人使用的飞书通知。目前使用体验良好。 如果不喜欢单独安装App的话，也可以考虑使用企业微信。企业微信可以绑定到微信内，我个人有其他业务是使用企业微信通知的。

引言 全局单例 组件化 运维通知

全自动Mud机器人是一种很典型的完美程序 完美的功能，解放人力 高度稳定性的代表 全面处理随机和意外 可以说，是对编写代码有兴趣，有热爱的Dream Project。 很多Mud玩家成为“高手”的标志之一。 当然，也会让很多人觉得，这很难，我做不到。 其实，只要开始做，全自动Mud机器人并没有这么难。 本系列的文章，会涉及编写全自动机器人的方方面面，帮助读者写出一个属于自己的，能顺畅运行的全自动机器人。 当然，在开始前，我们先要解决一个问题： 什么是全自动机器人？ 故名思议，全自动机器人就是能不需要人照顾的，自动完成某个人物的机器人。 理论上说，用一个定时器，每隔半小时在公开频道发布你要出售的道具的机器人，也算全自动机器人。 但这明显不符合我们的目标。 在此，我给全自动机器人下一个定义，全自动机器人是符合这样的两个条件而代码 在不需要人力维护的情况下，形成一种稳定循环，能控制状态和各种资源正向发展，不至于陷入困境而被动停摆 能够完成复杂任务获得回报 在这个定义下，我们能够明确的描述出我们这个系列研究的课题： 怎么才能让循环更稳定，控制更多的资源和状态？ 怎么才能完成更复杂的任务，获得更好的回报？