上帝类从__init__初始化多个职责对象起就已形成；识别信号包括：多依赖初始化、方法名混用动词前缀、单元测试需mock多个外部依赖；拆分应遵循GRASP信息专家原则，按数据归属分配职责，并通过依赖注入解耦。

直接说结论：上帝类不是写多了才出现的，而是从第一行 __init__ 开始就埋了雷——只要一个类同时承担“存数据、做计算、发通知、写日志、校验权限”，它就已经是上帝类了。

识别上帝类的三个信号

不用等代码长到1000行，这几个现象一出现，基本就能判定：

• self.users、self.email_service、self.logger、self.validator 全在一个 __init__ 里初始化
• 方法名混着用动词前缀：send_email、validate_user、log_action、export_csv
• 单元测试必须 mock 至少4个外部依赖才能跑通一个方法

拆分时优先按“信息专家”原则分配职责

GRASP 的 信息专家 原则比“高内聚低耦合”更具体：谁持有数据，谁就该处理跟那数据最直接相关的逻辑。别凭感觉分，看字段归属。

• 如果类里有 self.balance 和 self.currency，那 calculate_interest 就该归它；但 send_sms_alert 不该——短信服务不持有余额信息
• 如果 User 类里存了 self.role，权限检查逻辑可以留；但 generate_monthly_report 不该——报表需要聚合N个用户，不是单个用户的“信息”
• 遇到“这个功能该放哪儿”，先问：当前类有没有这个操作所需的全部数据？没有，就往外推，推给能拿到那些数据的协作方

用依赖注入代替内部创建，切断隐式耦合

上帝类常偷偷 new 出其他对象，比如在 process_order 里直接调用 EmailService() 或 DBConnection()。这会让测试和替换实现变得极难。

A Python CLI skill for Cutout.Pro visual APIs — background removal, face cutout, and photo enhancement. Supports file upload & image URL input.

调用 Cutout.Pro 视觉处理 API 进行背景移除、人像抠图和照片增强，支持文件上传与图片 URL 输入。

下载

立即学习“Python免费学习笔记（深入）”；

• 把外部依赖作为参数传进 __init__ 或方法，而不是在内部用 import + () 创建
• 接口要窄：不要传整个 Database 实例，只传需要的 save_user 函数或 Repository 接口
• 避免 if config.mode == 'prod': use_real_email() else: use_stub() 这种分支——那是配置逻辑，不该污染业务类

警惕“组合”变成新上帝类的温床

有人把上帝类拆成 UserManager + EmailSender + Logger，然后让 UserManager 持有后两者实例——这没解决问题，只是把上帝类换了个名字。关键不在拆，而在“谁控制谁”。

真正解耦的标志是：User 类完全不知道 EmailSender 的存在；EmailSender 只接受原始数据（如 user.email、template_name），不碰 User 对象本身。中间那层协调逻辑，应该放在用例层（比如 RegisterUserUseCase），而不是塞进某个实体类里。