BEE进阶研究第一季--Lua以元表元方法的形式模拟面向对象,让你的代码易读易改易维护

vshrd

行了行了 发表于 2025-9-18 02:24 PM
function myUnit:__tostring()
这样写的好处是不是新定义的tostring()指针对于myUnit，不会影响到其他的表 ...

晕.你这个回复论坛没提示.
我才偶尔看到.
回答一下问题.
就拿你说的三个技能来说
具体怎么写其实特别宽泛和发散.没有标准答案.我随便说个

创建技能基类.
创建技能派生类
利用派生类来进行不同类别技能的分类.如输出型技能,buff型技能.如果你想甚至还能继续细分.这里不一一列举
创建ABC三个技能的实例.
此时就可以利用面向对象的多态特性通过父级的虚方法来规定实例中的isRun条件

然后我们创建一个技能释放管理器,管理所有的技能实例.包括技能抉择和技能释放
这时面向对象的优势就来了,开始回答你的疑问.

对于技能管理器来说,我不需要知道每个技能实例的具体释放条件
我只需要执行每个实例的isRun()和Run()即可
对于技能的抽象类来说.我只负责管理我自身的逻辑,和对外(技能管理器)的公开方法.
别的什么技能,要怎样才能释放,自己并不关心.

所有的类都是相对独立的黑盒.
当有bug出现时,我会直接去对应的类中检查逻辑
而不是在茫茫几千行的代码中去排除bug.特别是在这种没有断点的情况下,更为复杂.

阅读成本为0也是这个意思.一眼看过去外部框架为技能管理器.除了一个list<Skill>的容器
和一个遍历调用所有技能的isRun & Run以外  没别的东西
如果我需要了解技能类的逻辑那就接着看技能类  如果不需要就不看.
不用考虑前后文直接有无依赖关系

当我们未来发现这套逻辑可能不符合当前的想法时,也无所谓.
甚至不需要更改.

因为技能管理器和技能实例之间的调用关系仅是skill的对外空开接口.
那么我们不管是直接修改这个公开接口,还是新建一个公开接口,
都只需要考虑一辆行的事儿.


其实这些思路在后面的帖子中已经有实现了
可能有人会觉得.你写的代码量并不少,远远多于我自己打地鼠的脚本.
但其实我们这里写的更复杂,是为了未来更简单和轻松过.
这一点等你在一个2000行以上量级的瀑布代码脚本里进行过调试排错增删逻辑后
就会切实体会到这一点了

行了行了

vshrd 发表于 2025-10-26 06:51 PM
晕.你这个回复论坛没提示.
我才偶尔看到.
回答一下问题.

大佬你说的我是一个都看不懂，什么是几类，什么是派生类
我又翻了你之前发的一系列教程，还是看的云里雾里的
包括论坛上其他一些大佬按照教程改用状态机写的脚本，我也没看懂
还是多沉淀下多思考下把，不懂得再问问AI吧
如果大佬有空希望能做个实例，比如将一个简单的bee if then end的脚本改成这种面向对象的写法，这样我们理解起来可能会更容易

vshrd

行了行了 发表于 2025-11-12 11:19 AM
大佬你说的我是一个都看不懂，什么是几类，什么是派生类
我又翻了你之前发的一系列教程，还是看的云里雾 ...

不好意思.回头看了看前文.好像确实没有解释.
但这里暂时不私下回复你了.
我会补充说明新开一贴重新讲一下.
但这个仅限于了解即可.
对实际代码帮助不大.
仅作为一些专有名词的补充.