上帝类违反单一职责原则，导致代码难理解、维护成本高、复用困难、测试失效；应按变更原因拆分职责、提取接口抽象、用策略模式解耦、提升可测性与可扩展性。
因为一个类承担太多职责，会直接导致代码难以理解、修改和测试。
上帝类让维护成本指数级上升
当一个类既处理用户登录、又管理订单生成、还负责日志记录和数据库连接时，任何一次业务调整都可能牵一发而动全身。比如修改密码策略，却意外影响了发票生成逻辑——只因它们共享同一套状态和私有方法。
- 每次改功能都要通读几百行甚至上千行代码
- 单元测试用例爆炸式增长，且极易相互干扰
- 多人协作时频繁出现合并冲突，因为都在改同一个文件
违背单一职责原则（SRP）
SRP不是“一个类只做一件事”的字面理解，而是“只有一个引起它变更的原因”。用户信息变更、支付网关升级、审计要求更新——这些本该由不同类响应的变化，若全压在一个类里，就等于把三把锁焊死在一把钥匙上。
- 识别变更原因：画出类中各方法背后的真实驱动因素（如“风控规则调整”“财政报税格式变化”）
- 按变更边界拆分：把日志相关逻辑抽成AuditLogger，把支付流程封装为PaymentProcessor
- 用接口隔离依赖：让主业务类只依赖Logger接口，而非具体实现
隐藏可复用性与扩展瓶颈
上帝类像一锅炖菜，所有原料混在一起，想单独拿出“胡萝卜”（比如用户认证模块）去其他项目复用？几乎不可能。更麻烦的是，新需求来了——比如要支持微信小程序登录，结果发现老登录逻辑和页面跳转、Session管理、Cookie写入全部耦合在一块，根本没法增量接入。
立即学习“Java免费学习笔记（深入）”；
- 提取稳定抽象：把“验证身份”定义为AuthenticationService接口
- 允许运行时替换：Web端用SessionBasedAuth，小程序用TokenBasedAuth
- 避免在上帝类里写if-else判断终端类型，那是策略模式的职责
测试失效与缺陷扩散
一个包含20个public方法的类，哪怕只覆盖其中5个方法的单元测试，也常因内部共享字段或静态状态而偶然通过。一旦某个私有工具方法出错，十几个业务路径同时崩溃，错误日志却只显示“NullPointerException at line 487”，没人知道那行代码到底服务于哪个场景。
- 小类天然适合测试：每个类对应一个明确输入/输出契约
- Mock更精准：测试订单服务时，只需mockInventoryClient，不用绕过整个上帝类的初始化逻辑
- 失败定位快：测试红了，基本就是这个类自己的问题，不是“又被隔壁模块带崩了”
