前言

本规范旨在旨在为 SLG（策略类游戏）服务器开发团队建立统一的软件开发准则，确保代码质量、可维护性和扩展性，以应对 SLG 游戏复杂的游戏逻辑、庞大的数据量和长期运营的需求。

核心开发准则

1. SOLID 原则

单一职责原则（Single Responsibility Principle）

• 定义：一个类应该仅有一个引起它变化的原因。

SLG 场景应用：

• 战斗计算类（BattleCalculator）只专注于战斗数值计算，不涉及战斗结果存储
• 示例：将 “城池” 类拆分为 CityData（数据存储）、CityService（业务逻辑）、CityView（数据展示）

里氏替换原则（Liskov Substitution Principle）

• 定义：子类应该能够替换其父类并保持原有行为的正确性。

SLG 场景应用：

• 所有兵种类（Infantry, Cavalry, Archer）继承自 Unit 类，任何使用 Unit 的地方都能无缝替换为具体兵种
• 不同类型的任务（DailyTask, MainTask, EventTask）继承自 Task，任务系统核心逻辑无需区分具体任务类型

接口隔离原则（Interface Segregation Principle）

• 定义：客户端不应依赖它不需要的接口。

SLG 场景应用：

• 将庞大的 Building 接口拆分为可独立实现的 SmallBuilding、DefensiveBuilding、ResourceBuilding 等
• 部队移动相关接口与攻击相关接口分离，非战斗单位无需实现攻击接口

依赖倒置原则（Dependency Inversion Principle）

• 定义：依赖于抽象而非具体实现。

SLG 场景应用：

• 战斗系统依赖于 Attackable 接口，而非具体的 Unit 类
• 数据存储模块依赖于 Storage 接口，可灵活切换 MySQL、Redis 等具体实现
• 示例：使用依赖注入框架管理服务之间的依赖关系

开闭原则（Open/Closed Principle）

• 定义：对扩展开放，对修改关闭。

SLG 场景应用：

• 通过策略模式扩展新的战斗计算公式，无需修改现有战斗框架
• 新的建筑类型通过继承 BaseBuilding 并实现特定接口来扩展，不修改原有建筑管理逻辑
• 使用事件驱动架构，新增游戏玩法只需订阅相关事件，无需修改事件发布者

---

2. DRY 原则（Don’t Repeat Yourself）

• 定义：系统中每一处知识都必须有唯一、明确、权威的表示。

SLG 场景应用：

• 统一的数值计算公式（如伤害计算、资源产出）应抽取为公共方法
• 玩家属性验证逻辑（如等级限制、资源足够性）应集中管理
• 使用配置表存储所有可配置数据（建筑升级所需资源、时间等）
• 避免在多个地方硬编码同一常量（如最大部队数量、资源上限）

---

3. SPOT 原则（Single Point of Truth）

• 定义：与 DRY 相似，强调任何数据或逻辑在系统中只应有一个权威来源。

SLG 场景应用：

• 玩家的当前资源数量以数据库中的值为唯一 truth，所有展示和计算以此为基础
• 游戏时间统一由 TimeService 提供，避免在各处使用系统时间
• 地图数据以地图服务中的数据为基准，其他模块通过接口获取而非缓存或复制

---

4. KISS 原则（Keep It Simple, Stupid）

• 定义：系统设计应尽可能简单，避免不必要的复杂性。

SLG 场景应用：

• 优先使用简单的解决方案，如能通过配置解决的问题就不要开发复杂逻辑
• 避免过度设计，新功能初期保持简单实现，随需求演进再重构
• 方法和类应保持短小精悍，单个方法代码量控制在 50 行以内
• 示例：资源不足时的提示逻辑直接返回错误码，而非设计复杂的提示生成系统

---

5. SoC 原则（Separation of Concerns）

• 定义：将系统划分为不同的部分，每个部分处理不同的关注点。

SLG 场景应用：

• 功能模块清晰划分：玩家模块、建筑模块、部队模块、战斗模块、任务模块等
• 模块间通过明确定义的接口通信，避免直接访问内部数据
• 示例：战斗结果计算与战斗日志记录分离为两个独立模块

---

6. YAGNI 原则（You Aren’t Gonna Need It）

• 定义：不要实现那些你认为未来可能需要的功能，只实现当前必需的功能。

SLG 场景应用：

• 不提前设计和开发 “可能在未来版本中用到” 的功能
• 新玩法开发只实现当前策划文档明确要求的功能点
• 避免过度抽象，仅在确实需要时才引入设计模式
• 示例：在确定需要多语言支持前，不要实现国际化框架

---

7. LoD 原则（Law of Demeter）

• 定义：一个对象应该对其他对象有最少的了解，只与直接朋友通信。

SLG 场景应用：

• 部队移动时，直接调用地图服务的移动接口，而非直接操作地图格子对象
• 建筑升级时，通过资源服务扣除资源，而非直接访问玩家的资源数据
• 避免链式调用：player.getArmy().getUnit(0).getWeapon().setDamage(100)
• 示例：使用中介者模式处理复杂的模块间交互

实施建议

• 代码审查：将上述原则纳入代码审查标准，确保团队成员共同遵守
• 定期重构：随着业务发展，定期检查并重构违反这些原则的代码
• 团队培训：通过实例讲解这些原则在 SLG 开发中的具体应用
• 技术分享：鼓励团队成员分享在实践中应用这些原则的经验和技巧
• 工具支持：使用静态代码分析工具检测潜在的原则违反情况

通过遵循这些软件开发准则，我们的 SLG 游戏服务器将具备更好的可维护性、可扩展性和可靠性，能够更高效地支持游戏的长期运营和版本迭代。