提炼子类是为了分离类中仅被部分实例使用的专属字段和方法，如SalesTarget与AchieveSalesTarget()，避免冗余、条件判断和null值，核心是识别并提取“不该共用”的逻辑。

提炼子类不是为了“多建一个类”，而是当一个类里混着两类（或更多类）的行为和数据，其中一部分字段或方法只对特定对象有意义时，把这部分“专属逻辑”拎出来，单独成类。核心在于识别出“不该共用”的那部分变量与行为。

什么时候该考虑提炼子类

关键信号是：类中存在明显分组的字段和方法，且它们只被部分实例使用——比如有字段 SalesTarget 和方法 AchieveSalesTarget()，但行政、技术岗员工根本用不到；或者某个布尔标志（如 isManager）一出现，后面就跟着一大串 if (isManager) { ... } 分支逻辑。

• 类中频繁出现条件判断，根据类型决定是否执行某段代码
• 某些属性在多数实例中始终为 null 或默认值（如 commissionRate 对非销售岗毫无意义）
• 测试用例明显分成两组：一组验证通用行为，另一组反复覆盖“特殊场景”分支

如何安全地提炼子类

操作不是简单复制粘贴，而是一步步剥离、验证、解耦：

• 先确认哪些字段和方法真正属于“子集语义”——例如 SalesEmployee 需要 SalesTarget、commissionRate、AchieveSalesTarget()、CalculateBonus()
• 新建子类继承原类，把专属字段声明为 public 或 protected（视封装需要），构造函数调用 base(...) 传入共用参数
• 把原类中所有针对该子集的条件逻辑（如 if (this is SalesEmployee) 或 if (isSales)）逐步替换成多态调用，或直接删掉——因为现在类型本身已表达意图
• 运行全部测试，尤其关注原类实例是否仍能正常创建、赋值、序列化，子类是否可独立使用

避免常见误区

提炼子类容易滑向两个极端：

• 过早抽象：仅因“将来可能有销售岗”就建子类，结果长期只有父类被使用，徒增维护负担
• 过度拆分：把本该用策略模式或配置驱动的差异（如不同计薪规则），硬塞进继承体系，导致子类爆炸
• 忽略构造一致性：子类构造函数未合理委托父类初始化，造成 Name、Salary 等基础字段遗漏或重复赋值

它和其它重构手法的关系

提炼子类常是继承体系优化的起点，后续可能自然触发其他动作：

• 若多个子类都新增了相同字段（如 departmentCode），就该考虑 Pull Up Field 上移到父类
• 若子类间行为高度相似但细节不同（如各类员工的考勤计算），可进一步用 Template Method 提炼骨架
• 若发现子类只复用父类极少能力，反而大量重写或屏蔽父类方法，就要警惕——这时 Replace Inheritance with Delegation 可能更合适