Java中是否允许抽象超类→具体子类→抽象子类的类层次结构？

Absolutely! Java fully supports the layered class structure you described: an abstract superclass → a concrete subclass → an abstract subclass → final concrete implementation classes. This pattern is actually quite useful for building flexible, reusable code where you want to layer functionality step by step. Let me break it down with a practical example to make it concrete.

How It Works (With Code Example) #

Let’s build a hierarchy around vehicles to illustrate each layer:

1. The Abstract Superclass #

Start with an abstract class that defines the core contract and shared behavior for all related classes:

public abstract class Vehicle {
    protected String brand;

    public Vehicle(String brand) {
        this.brand = brand;
    }

    // Abstract method all vehicles must implement
    public abstract void start();

    // Concrete method shared by all vehicles
    public void honk() {
        System.out.println(brand + " beeps loudly!");
    }
}

2. The Concrete Subclass #

Next, a concrete subclass that implements some abstract methods, adds its own logic, but leaves room for further specialization via a new abstract method:

public class MotorizedVehicle extends Vehicle {
    protected int powerReserve;

    public MotorizedVehicle(String brand, int powerReserve) {
        super(brand);
        this.powerReserve = powerReserve;
    }

    // Implement the start method with base motorized logic
    @Override
    public void start() {
        if (powerReserve > 0) {
            System.out.println(brand + " turns over and starts!");
            powerReserve -= 10;
        } else {
            System.out.println("Can't start " + brand + ": no power left!");
        }
    }

    // New abstract method for refueling/recharging logic
    public abstract void replenishPower();
}

Even though MotorizedVehicle is concrete (you could instantiate it directly), it declares an abstract method—making it a perfect parent for another abstract subclass.

3. The Abstract Subclass #

Now create an abstract subclass that adds vehicle-specific properties and behavior, but doesn’t implement all remaining abstract methods:

public abstract class Car extends MotorizedVehicle {
    protected int numberOfDoors;

    public Car(String brand, int powerReserve, int numberOfDoors) {
        super(brand, powerReserve);
        this.numberOfDoors = numberOfDoors;
    }

    // Concrete method unique to cars
    public void lockDoors() {
        System.out.println(brand + " car doors are locked securely!");
    }

    // We leave replenishPower() unimplemented—let final classes handle that
}

4. Final Concrete Implementations #

Finally, build concrete classes that extend Car and fill in the last abstract method with specialized logic:

public class ElectricCar extends Car {
    public ElectricCar(String brand, int batteryLevel, int numberOfDoors) {
        super(brand, batteryLevel, numberOfDoors);
    }

    @Override
    public void replenishPower() {
        System.out.println("Charging " + brand + " electric car to 100%...");
        powerReserve = 100;
    }
}

public class GasolineCar extends Car {
    public GasolineCar(String brand, int fuelLevel, int numberOfDoors) {
        super(brand, fuelLevel, numberOfDoors);
    }

    @Override
    public void replenishPower() {
        System.out.println("Filling " + brand + " gasoline car with fuel...");
        powerReserve = 100;
    }
}

When to Use This Pattern #

This layered hierarchy is ideal when you want to:

• Reuse code efficiently: Each layer adds shared logic without forcing all subclasses to implement everything upfront.
• Enforce clear contracts: Abstract methods at each level ensure specialized classes meet specific requirements.
• Build flexible extensions: You can add new concrete implementations (like HybridCar) later without modifying existing code, following the Open/Closed Principle.

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