如何重构含多子类的OOP代码以避免向下转型？

关于向下转型的实践判断 #

向下转型通常不属于良好实践：它会破坏编译期的类型安全，一旦传入错误的子类实例会直接抛出ClassCastException；同时会增加代码耦合度，后续新增子类时容易遗漏转型逻辑，大幅降低代码的可维护性。除非是处理遗留代码等极端场景，否则应该尽量避免。

避免向下转型的重构方案 #

方案1：泛型化HandleService接口 #

通过泛型限定接口的参数类型，让每个实现类直接对应具体的Service子类，从根源上消除转型需求：

// 泛型接口，限定为Common的子类
public interface HandleService<T extends Common> {
    String foo(T service);
}

// 实现类直接绑定ServiceX，参数类型明确
public class HandleServiceX implements HandleService<ServiceX> {
    @Override
    public String foo(ServiceX service) {
        // 直接访问Common的成员（继承而来）和ServiceX的专属成员
        int commonVal = service.getA();
        int xVal = service.getX1();
        return "Processed ServiceX: " + commonVal + ", " + xVal;
    }
}

// 主类调用时类型安全，不会传错参数
public class Main {
    public static void main(String[] args) {
        HandleService<ServiceX> handler = new HandleServiceX();
        handler.foo(new ServiceX());
    }
}

这个方案保留了你原有的"Service-Handler"分离结构，同时增强了类型安全，是最直接的优化方式。

方案2：将处理逻辑内聚到Service子类（遵循封装原则） #

既然处理逻辑依赖Service自身的成员，不如把逻辑直接放到Service类内部，消除额外的Handler类：

// 定义处理行为的接口
public interface Processable {
    String process();
}

// 公共父类不变
public class Common {
    int a;
    int b;
    int c;

    public int getA() { return a; }
    public int getB() { return b; }
    public int getC() { return c; }
}

// ServiceX继承Common并实现处理接口，逻辑内聚
public class ServiceX extends Common implements Processable {
    int x1;
    int x2;
    int x3;

    public int getX1() { return x1; }
    public int getX2() { return x2; }
    public int getX3() { return x3; }

    @Override
    public String process() {
        // 直接访问自身所有成员，无需任何转型
        return "ServiceX processed: " + getA() + ", " + getX1();
    }
}

// 主类调用简化
public class Main {
    public static void main(String[] args) {
        Processable service = new ServiceX();
        service.process();
    }
}

这个方案更符合封装原则，代码结构更简洁，适合处理逻辑与Service强绑定的场景。

方案3：访问者模式（适合复杂多场景处理） #

如果处理逻辑复杂且需要独立于Service存在，可使用访问者模式解耦Service和处理逻辑：

// 定义访问者接口，每个Service对应一个visit方法
public interface ServiceVisitor {
    String visit(ServiceX serviceX);
    String visit(ServiceY serviceY);
    // 新增Service子类时需要扩展此接口
}

// 公共父类改为抽象类，添加接受访问者的方法
public abstract class Common {
    int a;
    int b;
    int c;

    public int getA() { return a; }
    public int getB() { return b; }
    public int getC() { return c; }

    public abstract String accept(ServiceVisitor visitor);
}

// ServiceX实现accept方法，传递自身给访问者
public class ServiceX extends Common {
    int x1;
    int x2;
    int x3;

    public int getX1() { return x1; }
    public int getX2() { return x2; }
    public int getX3() { return x3; }

    @Override
    public String accept(ServiceVisitor visitor) {
        return visitor.visit(this);
    }
}

// 处理类实现访问者接口，直接获取ServiceX实例
public class HandleServiceX implements ServiceVisitor {
    @Override
    public String visit(ServiceX serviceX) {
        return "Handled ServiceX: " + serviceX.getA() + ", " + serviceX.getX1();
    }

    @Override
    public String visit(ServiceY serviceY) {
        // 根据需求处理，比如抛出异常或返回默认值
        throw new UnsupportedOperationException("Cannot handle ServiceY");
    }
}

// 主类调用
public class Main {
    public static void main(String[] args) {
        ServiceVisitor visitor = new HandleServiceX();
        Common service = new ServiceX();
        service.accept(visitor);
    }
}

该方案适合需要对不同Service做多样化处理的场景，但缺点是新增Service子类时必须修改访问者接口，违反开闭原则，仅在复杂场景下使用。

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