solid-grasp-yagni

Lens D —— SOLID / GRASP / YAGNI

经典原则做交叉验证。**这一 lens 最容易产出假阳性（教科书式建议）——严格用置信度门控，不报"理论上更优雅但无实际危害"的项。**

一、SOLID

S - 单一职责 (Single Responsibility)

• [ ] 每个类/模块只有一个变更理由
• [ ] 文件行数 ≤ 200（理想），> 400 需拆分
• [ ] 方法职责单一，不超过 30 行
• [ ] 没有"上帝类"或"万能工具文件"

违规：一个类同时处理业务逻辑+持久化+UI渲染；工具文件包含不相关函数集合；服务类承担过多业务领域。

O - 开闭 (Open/Closed)

• [ ] 扩展功能无需修改现有代码
• [ ] 使用抽象/接口而非具体实现
• [ ] 配置驱动而非硬编码

违规：大量 if-else/switch 判断类型；添加新功能需修改核心类；硬编码业务规则。

L - 里氏替换 (Liskov Substitution)

• [ ] 子类可完全替代父类
• [ ] 子类不削弱前置条件、不增强后置条件
• [ ] 继承层次合理，优先组合

违规：子类抛出父类未声明的异常；子类方法返回更窄类型；子类重写改变了语义。

I - 接口隔离 (Interface Segregation)

• [ ] 接口小而专注
• [ ] 客户端不依赖不需要的方法
• [ ] 没有"胖接口"

违规：接口 10+ 方法；实现类大量空方法/NotImplemented；接口混合不同角色职责。

D - 依赖倒置 (Dependency Inversion)

• [ ] 高层模块不依赖低层细节
• [ ] 依赖抽象而非具体
• [ ] 依赖注入正确使用

违规：直接 new 具体类而非注入；import 具体实现而非接口；循环依赖。

二、GRASP

| 模式 | 检查要点 | 典型违规 | |---|---|---| | **信息专家** | 职责给拥有所需信息的类；数据与行为同位 | 大量 getter 后在外部处理逻辑；贫血数据类 + 全能服务类 | | **创建者** | 对象创建职责分配合理；工厂得当 | 到处 new；创建逻辑与业务逻辑混合 | | **控制器** | 薄而专注，只接收+协调，不含业务逻辑 | 控制器 > 100 行；直接操作数据库；含复杂业务逻辑 | | **低耦合** | 模块间依赖最小化；用事件/消息解耦 | 一个改动引发大量文件修改；模块直接互引 | | **高内聚** | 类内元素紧密相关；方法操作相同数据 | 类中方法操作不同数据集；难以一句话描述职责 | | **多态** | 用多态替代条件判断 | 大量 instanceof/typeof；switch 判断对象类型 | | **纯虚构** | 辅助类设计合理，不破坏领域模型 | 过多 Helper/Util；服务类变上帝类 | | **间接性** | 中间层确实降低耦合，不过度间接 | 为解耦而过度抽象；调用链过长难追踪 | | **防变异** | 变化点被接口隔离；外部依赖被封装 | 外部 API 直接渗透业务层；第三方库耦合核心 |

三、YAGNI —— 反过度工程（审查者自己也要守）

**You Aren't Gonna Need It.** 审查时**推销抽象 = 违反 YAGNI**，这是架构审查最大的自我失败模式。

• [ ] 没有"以防万一"的代码
• [ ] 没有未使用的抽象层
• [ ] 没有预留的扩展点（无实际需求）
• [ ] 没有过度设计的泛型

**精简硬标准：**

• [ ] 每个抽象都有 **≥2 个实现**
• [ ] 每个接口方法都被调用
• [ ] 每个配置项都被使用
• [ ] 没有 dead code

违规：空接口"为将来准备"；复杂配置系统只用一种配置；泛型工厂只生产一种产品；未使用的参数/方法；注释掉的"备用"代码。

> 自检：当你想建议"加一个接口/工厂/抽象层"时，先回答——**现在有几个真实实现？有几个已知的真实变化点？** 答不出 ≥2，就不要报这条。