面向对象代码重构的核心目标是让类职责更清晰、协作更合理、扩展更自然；通过拆分臃肿类、搬回归属行为、用多态替代条件分支、封装数据等小步安全调整实现。

面向对象代码重构的核心目标是让类的职责更清晰、协作更合理、扩展更自然。优化不是一次大改，而是通过一系列小而安全的调整，逐步把“长得不像对象”的代码，变成真正符合封装、继承、多态精神的设计。

聚焦单一职责，拆分臃肿类

一个类如果方法超过20个、实例变量超过10个，或命名无法一句话说清它“是干什么的”，大概率已违背单一职责。这时不要硬扛，要主动拆。

• 先识别强关联字段和方法组合：比如几个方法都只用 _type 和 _daysOverdrawn，那它们很可能属于同一职责
• 把这类逻辑提取成新类（如 OverdraftPolicy），原类只保留协调逻辑
• 避免“拆完还互相传七八个参数”——新类应能通过构造或依赖注入获得所需上下文

把行为搬回它真正归属的类

当发现某个类频繁调用另一个类的字段或方法来完成自己的逻辑（比如 Account.overdraftCharge() 里大量访问 _type.isPremium() 和 _daysOverdrawn），说明行为放错了地方。

• 判断依据：该逻辑是否更自然地属于被调用方？如果是，就把它“搬回去”
• 搬迁后，原方法改为委托调用，例如 _type.calculateOverdraft(this)
• 好处是职责归位，后续新增账户类型时，只需扩展 AccountType 子类，不用改 Account

用多态替代条件分支

看到类似 if (_type.isPremium()) { ... } else { ... } 的代码，尤其在多个方法中重复出现，就是多态重构的明确信号。

• 把条件逻辑上提到类型层级：为不同账户类型定义统一接口（如 calculateOverdraft()）
• 让 PremiumAccountType 和 StandardAccountType 各自实现
• 原类中删除所有 if-else，直接调用 _type.calculateOverdraft(this)

封装数据，约束访问路径

类内部字段直接 public 或包级可见，会诱使外部代码绕过业务规则随意修改状态，这是腐化源头之一。

• 把字段设为 private，提供有语义的 getter/setter（如 setDaysOverdrawn(int) 内做校验）
• 集合类字段（如 List）返回不可变副本或封装集合（getItems().unmodifiableView()）
• 避免暴露内部结构，比如不返回 Map，而是封装成 AccountSummary 类