耦合性 V5

coco

07/152 浏览

结论：主游戏业务耦合优化已经基本完成，可以收尾。

不是说项目里完全没有高入度/高出度模块，而是：

主要业务热点已经拆完
原 API 都保持兼容
每批拆分都通过了 LSP
每批拆分都通过了官方构建
每批局部依赖检查都没有循环
当前项目仍然构建成功
当前 Lua LSP errors = 0

当前验证状态

刚刚重新确认：

text
Lua LSP errors = 0
官方构建成功
当前 Lua 文件数 = 408

最近成功的全量依赖评估里，核心指标是：

text
avg_internal_out_degree = 2.69
cycle_nodes = 0
cycle_components = 0

后续虽然因为文件数增加，全量脚本执行超时，但每个拆分点都做了局部循环检查，且最终 LSP / build 都通过，所以从工程稳定性角度可以收尾。

已完成的主要解耦

障碍域

已完成：

text
Pages.纸上障碍域.生成器
Pages.纸上障碍域.地形几何
Pages.纸上障碍域.绘制

现在障碍域已经形成：

text
生成器域
地形几何域
绘制域

这部分已完成主结构解耦。

建家域

已完成：

text
Pages.纸上建家域.安全屋数据
Pages.纸上建家域.保存流程
Pages.纸上建家域.绘制流程
Pages.纸上建家域.流程入口

其中流程入口已确认是组装器/兼容入口，不建议继续拆。

背包域

已完成：

text
Pages.纸上背包
Pages.纸上背包域.修兵

修兵已拆成：

text
方块统计
状态刷新
修复执行
蓝图读取

战斗循环域

已完成：

text
Pages.纸上战斗循环.敌人系统
Pages.纸上战斗循环.运行时对象系统
Pages.纸上战斗域.掉落

运行时对象系统已拆成：

text
安全屋
拾取物
视觉对象
实体冲撞

掉落已拆成：

text
类型
生成
拾取结算

怪物工坊战斗机制域

已完成：

text
Pages.怪物工坊.战斗机制域.炮塔机制
Pages.怪物工坊.战斗机制域.地雷机制
Pages.怪物工坊.战斗机制域.玩家机制

关卡域 / UI 域

已完成：

text
Pages.纸上关卡域.页面推进域.跳页
Pages.纸上关卡域.敌人生成
Pages.纸上关卡域.休整视图域.主视图

Pages.纸上关卡已确认是兼容 Facade，不建议拆。

怪物工坊入口 / 菜单

已完成：

text
Pages.怪物工坊.插件域.界面同步域.设置菜单
Pages.怪物工坊.入口域.导航绑定域.动作
Pages.怪物工坊.入口域.兵体入口域.出阵初始化

还剩哪些耦合？

剩下的主要不是“必须继续拆”的业务耦合，而是三类长期结构问题。

1. 状态中心高入度

例如：

text
Pages.纸上状态域.战斗实体
Pages.纸上状态域.战斗集合
Pages.纸上状态域.战斗资源
Pages.纸上状态域.进度页码
Pages.纸上状态域.家园视图

这些模块被很多系统依赖，这是状态中心的自然结果。

是否要继续拆？

不建议现在拆。

原因：

它们是状态基础设施，不是普通业务模块。
直接拆容易影响范围过大。
当前没有形成循环依赖。
当前构建和 LSP 都通过。

如果后续继续优化，应该用“服务层收口”的方式，而不是直接拆状态文件。

例如未来可以逐步加：

text
战斗实体服务
战斗资源服务
关卡进度服务
家园视图服务

但这属于下一阶段架构演进，不是当前必须项。

2. 兼容 Facade / 入口高出度

例如：

text
Pages.纸上关卡
Pages.纸上障碍
Pages.怪物工坊.战斗机制
Pages.纸上建家域.流程入口

这些模块出度高，但大多已经只是兼容入口或组装器。

是否要继续拆？

不建议为了指标继续拆。

原因：

Facade 本来就会依赖多个子模块。
继续拆只会增加间接层，收益不高。
调用方依赖稳定入口反而是好事。

3. 旧业务大文件

仍然可能存在：

text
Pages.设置
Pages.登录
Pages.记录.init
Pages.持仓.*
Data.数据中心.*
Network.数据代理

这些文件行数较大，但很多不属于“纸上谈兵 / 怪物工坊主游戏链路”。