协同进化原本是生物学中描述物种相互影响、共同演化的概念，放到Java继承体系里，可以理解成父类与子类在功能迭代过程中保持同步更新，而不是各自独立变化。父类一旦修改核心逻辑，子类要么自动继承新行为，要么通过受控重写参与差异实现，同时避免破坏已有调用方的契约。
Java提供的方法分派和super调用机制，是父子类协同进化的底层支撑。子类对象调用一个方法时，虚拟机会先查找子类是否重写了该方法；如果重写了，就执行子类版本，否则执行父类版本。这种动态绑定让子类可以替换父类行为，但也带来一个常见问题：子类完全覆盖父类方法时，父类后续新增的通用逻辑可能被直接跳过。因此，在需要同步更新的场景中，通常要在子类重写方法里调用super方法，或者把父类方法设计成不可重写的模板方法，让子类只能填充特定扩展点。
方法分派与super调用：同步更新的底层机制
理解父类与子类的同步更新，先要区分隐藏和覆盖。实例方法可以被覆盖，静态方法只能被隐藏，字段则只会被隐藏。覆盖实例方法时，编译器会根据引用类型检查方法是否存在，但运行时按实际对象类型分派。假设父类定义了一个通用处理方法，子类重写该方法后又调用了super，就能在执行自有逻辑之前或之后复用父类逻辑。这样做的好处是父类逻辑升级后，子类无需改动即可同步获得新能力。
如果子类重写时完全不调用super，父类里后来补充的校验、日志、缓存等通用逻辑就会丢失。来看一段代码：
public class BaseService {
public void execute() {
beforeExecute();
doExecute();
afterExecute();
}
protected void beforeExecute() {
System.out.println("Base beforeExecute: logging start");
}
protected void doExecute() {
System.out.println("Base default execution");
}
protected void afterExecute() {
System.out.println("Base afterExecute: logging end");
}
}
public class OrderService extends BaseService {
@Override
protected void doExecute() {
System.out.println("Order processing");
}
}
上面的父类封装了执行前后处理，子类只重写doExecute方法。父类如果以后在beforeExecute中增加权限校验，所有子类的执行入口都会自动获得这个校验，而不需要修改OrderService。这正是协同进化想要的效果：父类维护通用流程，子类维护差异步骤，两者同步更新而不互相干扰。
不过，字段隐藏和静态方法隐藏容易引起混淆。如果父类和子类声明了同名实例字段，子类字段并不会覆盖父类字段，而是各自存储，访问哪一份取决于引用类型。同步更新时应该避免字段隐藏，尽量通过protected方法暴露状态读取和修改，让父类和子类只通过方法交互。
模板方法模式：父类控制流程，子类只填差异
模板方法模式是父子类协同进化的典型实现。父类把一个算法的骨架固定为final方法，内部按顺序调用若干个步骤方法，其中可变步骤留给子类实现。这样父类的整体流程修改会立即同步到所有子类，同时子类只负责局部差异，不会破坏父类流程。
来看一个更完整的例子。假设系统需要处理不同渠道的订单，所有订单都要经过参数校验、库存扣减、支付和通知四个阶段，其中参数校验对所有渠道一致，库存扣减和支付可能不同，通知可以统一。父类可以这样设计：
public abstract class OrderProcessor {
public final void process(Order order) {
validate(order);
decreaseStock(order);
pay(order);
notifyUser(order);
}
private void validate(Order order) {
System.out.println("Validating order: " + order.getId());
}
protected abstract void decreaseStock(Order order);
protected abstract void pay(Order order);
private void notifyUser(Order order) {
System.out.println("Notifying user for order: " + order.getId());
}
}
public class OnlineOrderProcessor extends OrderProcessor {
@Override
protected void decreaseStock(Order order) {
System.out.println("Decrease stock for online order");
}
@Override
protected void pay(Order order) {
System.out.println("Pay online order");
}
}
父类process方法被声明为final，子类无法整体覆盖，只能实现decreaseStock和pay。如果后续所有订单需要增加风控检查，只需在process方法中调整逻辑，例如在validate之后调用riskCheck，所有子类立即获得该步骤。父类私有方法也可以避免子类直接修改。
模板方法模式的价值在于扩展点被显式定义。父类清楚哪些步骤允许子类参与，哪些步骤必须由自己控制。这样父子类之间有了稳定的协同契约，父类升级不会侵入子类的核心实现，子类增加渠道时也无需理解整个流程。当然，扩展点不宜过多，否则父类流程会失去约束力，子类之间容易出现重复逻辑。
抽象类与接口契约：约束父子类演进边界
在父类与子类同步更新时，抽象类和接口承担着不同的契约职责。抽象类可以包含已实现方法、抽象方法和protected状态，适合定义模板流程和公共状态；接口在Java 8之后可以包含默认方法和静态方法，适合描述能力约束。父类新增抽象方法会强制所有子类实现，这在框架升级时可能造成破坏；而接口新增默认方法则不会强制已有实现类修改，因此具有更好的兼容性。
例如，早期版本定义了一个PaymentGateway接口，只有pay一个方法。后来需要增加退款能力，如果直接在接口中增加抽象方法refund，所有已有实现类都会报错。可以选择提供默认实现：
public interface PaymentGateway {
void pay(Order order);
default void refund(Order order) {
throw new UnsupportedOperationException("Refund not supported");
}
}
这样已有实现类不必立即支持退款，新实现类可以覆盖refund。父类或接口的设计者需要在功能扩展和向后兼容之间权衡。抽象类的情况类似，但抽象类通常承载更多实现细节，新增抽象方法的影响面更大。可以采用引入新接口或新抽象方法并提供默认实现的策略，降低子类的同步压力。
另外，抽象类应尽量把扩展点定义为protected abstract，这样外部调用方不会看到这些方法，子类则必须实现。接口默认方法也可以调用其他接口方法，形成简单的模板效果，但由于接口不能有实例字段，状态管理仍需实现类完成。设计时先判断是“需要共享状态和流程”还是“只约束能力”，再选择抽象类或接口。
兼容性策略与重构：避免父类修改破坏子类
父子类协同进化最大的风险是父类版本升级导致子类行为异常或编译失败。除了新增抽象方法，父类修改方法签名、改变返回类型、收紧访问权限、修改protected方法的语义，都可能让已有子类无法编译或运行时出错。因此，父类在设计之初就要区分稳定部分和可变部分，稳定部分用final保护，可变部分通过抽象方法或钩子方法暴露，并保持语义清晰。
一个常见的坑是父类构造器中调用可重写方法。子类构造时，父类构造器先执行，此时子类字段还没有初始化，如果父类构造器调用子类重写的方法，可能读取到默认值或抛出空指针。下面这段代码演示了这个问题：
public class Base {
public Base() {
init();
}
protected void init() {
System.out.println("Base init");
}
}
public class Child extends Base {
private String name;
public Child(String name) {
this.name = name;
}
@Override
protected void init() {
System.out.println("Child init, name length: " + name.length());
}
}
创建Child对象时会触发父类构造器，父类构造器调用init时子类的name还是null，因此name.length()会抛出NullPointerException。避免办法是父类构造器不要调用可重写方法，或者把初始化逻辑放在静态工厂方法中，等对象完整创建后再调用。
另一个策略是使用组合代替继承。当发现父类和子类之间需要频繁同步但行为差异很大时，继承可能不是最佳选择。可以定义一个稳定接口，把可变策略封装成独立对象，让主类持有策略引用。这样既能灵活替换行为，又不会因为父类修改而影响子类体系。不过，模板方法模式仍然适合流程骨架固定的场景，选择组合还是继承要根据业务变化方向判断。
总体而言，Java中的父类与子类协同进化，核心是建立清晰、受控的扩展点，并理解方法分派与super调用带来的同步机制。父类负责稳定流程和公共逻辑，子类在约定边界内扩展差异，同时通过模板方法、抽象契约和兼容性策略降低升级风险。