UnityAI调整

rules/20-开发规则.md

@@ -32,6 +32,56 @@
 - `if`、`else`、`for`、`foreach`、`while`、`do` 等控制语句必须使用 `{}`，即使语句体只有一行也不得省略。
 - 所有方法必须完整书写方法体和 `{}`，禁止使用表达式体（`=>`）等省略写法。
 
+## 面向对象设计六大原则（辅助参考）
+
+以下原则仅用于辅助理解职责、依赖和扩展方式，不作为独立的强制开发规则或验收门槛。以现有开发规则、项目架构、兼容性要求和实际需求为准；存在取舍时，不用六大原则覆盖这些约定。
+
+遇到相关设计问题时按需参考，无需每次开发逐条检查或说明不采用的理由。优先复用项目现有结构，选择最小可行实现；不能仅因某段代码不符合某项原则就要求拆类、增加接口、引入模式或重构。
+
+### 1. 单一职责原则（SRP）
+
+- 一个类或模块应围绕一个内聚职责组织，具有同一类变更原因；不按方法数量或代码行数机械拆类。
+- 展示、业务状态、网络传输和资源加载等独立变化的职责应有明确边界，避免集中到一个窗口、MonoBehaviour 或万能管理器中。
+- 方法围绕一个明确目的组织；可以组合步骤，但不夹带无关副作用。拆分时复用现有模块，避免只有转发作用的空壳层。
+
+### 2. 开闭原则（OCP）
+
+- 对已经确认的变化点，优先通过现有配置、组合、策略或扩展入口增加行为，减少反复修改稳定核心流程。
+- 不为尚不存在的变化预建扩展体系，也不为了消除所有 `if` / `switch` 强行引入模式。
+- 修复缺陷或调整已有行为仍可直接修改源码；涉及公共接口、协议或数据兼容性时，按工作流确认影响并验证现有调用。
+
+### 3. 里氏替换原则（LSP）
+
+- 子类型替换基类型后，必须继续满足调用者依赖的契约：不加强前置条件、不削弱结果保证，并保持基类不变量及约定的失败行为。
+- 不以空实现、无条件抛出“不支持”异常或额外类型判断掩盖不成立的继承关系；无法满足契约时优先组合或拆分能力接口。
+- Unity 生命周期重写必须遵循当前基类的初始化、清理和完成回调契约；不能只看签名相同就认为可替换。对修改影响的基类调用路径做针对性验证。
+
+### 4. 依赖倒置原则（DIP）
+
+- 高层业务规则与易变的底层细节通过稳定契约协作；抽象围绕业务需要定义，不能只是复制底层 SDK 的全部接口。
+- 沿用项目已有接口、事件和公开入口；底层框架不得反向依赖具体游戏业务。程序集方向仍遵循 [架构说明](10-架构说明.md)。
+- 需要隔离网络、平台 SDK、存储等易变实现时，在明确边界使用接口、委托或现有桥接机制；不要求每个具体类都有接口，不新增无必要的容器或全局服务定位层。
+
+### 5. 接口隔离原则（ISP）
+
+- 调用方只依赖自己需要的能力；不要让实现类因一个大接口被迫提供无关方法或无效实现。
+- 按内聚的角色与能力拆分接口，避免万能接口；也不机械拆成大量单方法接口。
+- 扩展共享接口前检查所有实现者与调用者，评估兼容性；独立能力优先使用独立契约，不随意给既有公共接口加成员。
+
+### 6. 迪米特法则（LoD，最少知识原则）
+
+- 模块通过直接协作对象的公开能力完成工作，避免穿透多个对象的内部结构、任意修改其他模块状态或依赖易变的深层节点路径。
+- 优先通过项目现有管理器入口、查询方法或事件交互，减少对他人内部实现的了解；合法的数据读取和集合访问不因调用链长就机械包装。
+- 不为了缩短调用链添加无意义的转发层，也不把所有调用改成全局事件或单例。状态由所属模块维护，生命周期与事件解绑责任必须明确。
+
+### 辅助使用边界
+
+- 需要分析职责或依赖问题时，可借助相关原则判断；不要求逐项打勾，不靠类名或模式数量评价代码，也不把完全符合六大原则作为完成条件。
+- 不顺带重构无关历史代码；发现既有问题时说明影响，只有阻碍当前需求且获得对应范围授权时才调整。
+- 原则与现有开发规则、兼容性、性能或交付范围发生取舍时，以当前规则与实际需求为准；仅对影响本次行为或维护成本的实际取舍作必要说明。公共接口和架构调整仍遵守 [工作流清单](40-工作流清单.md)。
+- Unity 中同时核对序列化、Prefab 引用、生命周期、资源释放与目标平台限制；原则不能成为破坏这些约束的理由。
+- 验证与改动匹配：检查受影响的调用者和实现者，必要时验证替换行为、边界失败路径及资源清理。文档检查或编译通过不代表运行时契约已经得到验证。
+
 ## 框架与业务边界
 
 - 业务代码通过 `HFFunCatalogue` 等统一入口访问资源、UI、场景和其他框架能力。