Java无“is a”关系类的共享方法复用方案咨询

这个场景我之前做项目时也碰到过，明明一堆代码重复得让人难受，但两个类又确实没有“is-a”的继承关系，硬套继承总觉得别扭。结合你的情况，给你几个实用的解决方案，你可以根据代码的具体需求来选：

1. 利用Java 8+的接口默认方法 #

如果你之前已经定义了公共接口，那直接在接口里给共享方法加上default实现是最省事的——只要这些方法不需要访问类的私有成员或实例字段就行。

举个例子：

public interface CommonOperations {
    // 共享方法的默认实现
    default void logOperation(String operationName) {
        System.out.println("执行操作：" + operationName);
        // 其他通用逻辑...
    }
    
    // 每个类需要自己实现的方法
    void doSpecificTask();
}

// 两个业务类实现接口后，自动拥有logOperation方法
public class ClassA implements CommonOperations {
    @Override
    public void doSpecificTask() {
        // ClassA的专属逻辑
    }
}

public class ClassB implements CommonOperations {
    @Override
    public void doSpecificTask() {
        // ClassB的专属逻辑
    }
}

这种方式完全符合接口的设计初衷，而且不需要额外的类，代码也简洁。但要注意：默认方法不能访问类的内部状态，要是共享逻辑需要用到业务类的私有字段，这个方案就不适用了。

2. 提取共享逻辑到工具类（组合模式） #

把那些相同实现的方法抽出来，放到一个独立的工具类里，然后在两个业务类中通过组合的方式复用这些逻辑——这也是“优先组合而非继承”原则的典型应用。

比如：

// 封装所有共享逻辑的工具类
public class CommonLogicHelper {
    // 如果需要业务类的状态，可以通过参数传入
    public void processCommonData(BusinessContext context) {
        // 通用处理逻辑，比如使用context提供的公共方法获取数据
        String data = context.getSharedData();
        System.out.println("处理通用数据：" + data);
    }
    
    // 无状态的通用方法可以写成静态的
    public static void commonStaticMethod() {
        // 无状态的通用逻辑
    }
}

// 定义一个公共接口，让业务类提供必要的上下文
public interface BusinessContext {
    String getSharedData();
}

// ClassA实现BusinessContext，组合CommonLogicHelper
public class ClassA implements BusinessContext {
    private CommonLogicHelper helper = new CommonLogicHelper();
    
    @Override
    public String getSharedData() {
        return "ClassA的数据";
    }
    
    public void sharedMethod() {
        helper.processCommonData(this);
    }
}

// ClassB同理
public class ClassB implements BusinessContext {
    private CommonLogicHelper helper = new CommonLogicHelper();
    
    @Override
    public String getSharedData() {
        return "ClassB的数据";
    }
    
    public void sharedMethod() {
        helper.processCommonData(this);
    }
}

这种方式完全解耦了业务类和共享逻辑，后续修改共享代码也不会影响业务类的独立性，非常灵活。

3. 谨慎使用抽象父类（你考虑的方案） #

如果两个类虽然没有严格的“is-a”关系，但共享逻辑非常多，且强行继承不会带来逻辑上的混淆，也可以用抽象父类来复用代码。但一定要注意：不要为了复用代码而破坏类的语义。

比如如果两个类都是某种“服务类”，只是处理的业务不同，那抽象一个BaseService父类是合理的；但如果一个是User，一个是Order，硬让它们继承同一个父类就会让代码变得难以理解。

示例：

public abstract class BaseBusinessClass {
    // 共享方法的默认实现
    protected void commonSetup() {
        // 通用初始化逻辑
    }
    
    // 抽象方法，让子类实现专属逻辑
    public abstract void doBusiness();
}

public class ClassA extends BaseBusinessClass {
    @Override
    public void doBusiness() {
        // ClassA的业务逻辑
    }
}

public class ClassB extends BaseBusinessClass {
    @Override
    public void doBusiness() {
        // ClassB的业务逻辑
    }
}

这个方案的好处是和继承的体验类似，子类可以通过super调用父类的方法，但缺点是Java是单继承，后续如果子类需要继承其他类就会受限，而且容易导致类层次混乱。

4. 委托模式（模拟继承的复用体验） #

如果你想要类似继承中super的复用体验，但又不想用真正的继承，可以用委托模式：定义一个包含所有共享方法的委托类，让业务类实现公共接口，同时把接口方法的实现委托给这个委托类。

示例：

public interface SharedMethods {
    void methodA();
    void methodB();
}

// 委托类，实现所有共享方法的通用逻辑
public class SharedDelegate implements SharedMethods {
    @Override
    public void methodA() {
        System.out.println("通用的methodA实现");
    }
    
    @Override
    public void methodB() {
        System.out.println("通用的methodB实现");
    }
}

// ClassA实现接口，通过委托复用逻辑，还可以选择性重写
public class ClassA implements SharedMethods {
    private SharedDelegate delegate = new SharedDelegate();
    
    @Override
    public void methodA() {
        // 直接复用委托类的实现
        delegate.methodA();
    }
    
    @Override
    public void methodB() {
        // 先调用通用实现，再添加自己的逻辑
        delegate.methodB();
        System.out.println("ClassA额外的methodB逻辑");
    }
}

这种方式既保留了继承的灵活性（可以选择性重写方法），又避免了继承的耦合问题，是很多场景下的最优解。

总结一下：如果共享方法不需要访问业务类的内部状态，优先用接口默认方法；如果需要访问内部状态，推荐用委托模式或组合工具类；抽象父类尽量少用，除非类的语义确实允许。

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