如何实现类按需指定父类的继承？泛型方案可行性咨询

现有类继承结构如下：

public abstract class Base<T>
public class OriginBase<T extends CustomObject> extends Base<T>
public class Middle<T extends CustomObject> extends OriginBase<T>

public class A extends Middle<ObjectA>
public class B extends Middle<ObjectB>
public class C extends Middle<ObjectC>

因类A的新功能开发，需要使用OriginBase的新版本NewBase（仅新增少量方法），但由于B、C等类仍依赖原继承链，无法直接修改Middle的父类为NewBase。

目前的临时方案是创建继承自NewBase的NewMiddle，复制Middle中的所有重写方法让A继承，但会产生数百行重复代码。

尝试通过泛型继承优化，思路是让A、B、C各自指定所需的Base类，草拟代码如下：

public abstract class Base<T>
public class OriginBase<T extends CustomObject> extends Base<T>
public class NewBase<T extends CustomObject> extends Base<T>
public abstract class CommonBase<B extends Base>

// 不确定泛型定义是否正确
public class NewMiddle<B extends Base<T extends CustomObject>, T> extends CommonBase<B, T>

// 修改后的类
public class A extends Middle<NewBase<ObjectA>>
// 其他类
public class B extends Middle<OriginBase<ObjectB>>
public class C extends Middle<OriginBase<ObjectC>>

想请教该泛型方案是否可行？如何正确实现这类继承？

一、你草拟方案的问题 #

你的代码存在两处关键问题：

1. 泛型约束语法错误：B extends Base<T extends CustomObject> 不符合Java泛型语法规则，类型参数的边界需要单独声明。
2. 类型匹配错误：原Middle类的泛型参数是T extends CustomObject，但修改后A extends Middle<NewBase<ObjectA>>传入的是Base子类，和原约束的CustomObject子类类型不匹配。

二、可行的泛型重构方案 #

核心思路是让Middle通过泛型参数动态指定父类类型，彻底复用原有代码，避免冗余。具体实现如下：

1. 重构Middle类，引入父类泛型参数 #

把Middle改为双泛型类，同时指定业务类型T和父类类型P：

// P约束为Base<T>的子类，T保持原有的CustomObject子类约束
public class Middle<T extends CustomObject, P extends Base<T>> extends P {
    // 保留原Middle中的所有方法逻辑，无需修改
}

2. 调整子类继承逻辑 #

• 类A指定使用NewBase作为父类：

public class A extends Middle<ObjectA, NewBase<ObjectA>> {
    // 直接调用NewBase新增的方法即可
}

• 类B、C继续沿用原OriginBase：

public class B extends Middle<ObjectB, OriginBase<ObjectB>> {}
public class C extends Middle<ObjectC, OriginBase<ObjectC>> {}

3. 方案优势 #

• 完全复用Middle中的代码，没有任何重复。
• 子类可以灵活选择父类实现，后续如果有新的Base子类，直接通过泛型参数指定即可，无需修改原有结构。

三、备选方案：组合替代继承 #

如果泛型重构带来的复杂度超出预期，可以考虑用组合模式替代继承：

1. 在Middle中新增一个Base<T>类型的成员变量，而非继承它。
2. Middle中的所有方法通过委托调用该成员变量的对应方法。
3. 类A初始化时传入NewBase<ObjectA>实例，B、C传入OriginBase实例。
   这种方式更符合“优先组合而非继承”的设计原则，适合后续有更多扩展需求的场景，但需要修改Middle的方法实现逻辑。

内容的提问来源于stack exchange，提问作者Hayate