面向对象重构的核心是贴近业务逻辑、职责清晰、扩展自然，关键在识别重复、解耦依赖、明确边界；信号包括参数重复传递、数据手动流转、条件分支膨胀；应按收拢→拆分→抽象三步推进，避免巨型类、贫血模型和过度设计。
面向对象重构不是把函数塞进类里就完事，核心是让代码更贴近业务逻辑、职责更清晰、扩展更自然。关键在识别重复、解耦依赖、明确边界。
从“过程式”到“对象化”的识别信号
当你发现这些情况，就是该考虑重构的信号：
- 多个函数反复接收相同的一组参数（比如
user_id, config, db_conn）→ 这些参数很可能属于一个隐含的实体，适合封装成类 - 同一份数据在不同函数间被手动传递、拼接、校验 → 它可能该有自己的状态和行为，比如
OrderData类统一管理校验、序列化、状态流转 - 条件分支越来越多（如
if type == "email": ... elif type == "sms": ...），且每种类型处理逻辑差异大 → 考虑策略模式或继承体系，用多态替代if-else
重构三步走：先收拢，再拆分，最后抽象
别一上来就设计完美类图，按节奏推进更稳妥：
-
收拢：把相关函数和数据归到一个模块或临时类中，不改逻辑，只调整作用域。例如把所有用户权限检查函数移到
UserPermission类里，方法暂为@staticmethod -
拆分：识别职责，划出边界。比如原有一个
process_order()函数，实际做了库存扣减、发通知、记日志三件事 → 拆成InventoryService、NotificationSender、OrderLogger三个类，各自专注一件事 -
抽象：提炼共性，引入接口或基类。当出现
SmsSender、EmailSender、PushSender时，定义NotificationSender协议（用typing.Protocol或抽象基类），让调用方只依赖抽象，不绑定具体实现
避免常见“伪面向对象”陷阱
重构不是加了class就高级了，警惕这些反模式：
立即学习“Python免费学习笔记（深入）”；
- 巨型类（God Class）：一个类几百行，包揽创建、校验、存储、渲染——它其实是一堆职责的缝合怪。应按变化原因拆分（比如“数据怎么来”和“数据怎么用”通常变因不同）
-
贫血模型：类只有
__init__和一堆get_/set_方法，业务逻辑全在外层函数里跑 → 把行为“推回”对象内部，比如user.activate()比activate_user(user)更能体现主体动作 - 过度设计接口：还没出现第二个实现，就急着抽抽象基类 → 先写两个具体类，等第三处需要复用时再提炼，遵循“三次法则”
验证重构是否成功的简单标准
改完别急着合代码，快速自问几个问题：
- 新增一种类似场景（如支持新支付渠道），是否只需加一个类、改一处注册点，而不用动原有逻辑？
- 想测试某个业务规则（如“VIP用户免运费”），是否能单独实例化对应对象、传入模拟数据、断言结果，不启动数据库或网络？
- 新同事看
order.py，能否不翻其他文件就大致理解订单的核心状态和关键操作？
