编辑：

需要明确的一点是：设计很丑陋并不是事实。关键是，设计在那里，我不得不添加另一个子类，FlyingMotorizedVehicle如果我忘记添加的话，该子类将无法按预期工作foo(...)。所以我只是想知道是否可以将其重新定义为抽象。

我现在正面临一个非常奇怪的继承情况。比方说，我有三个班，Vehicle，MotorizedVehicle并且FlyingMotorizedVehicle还有一堆课Airplane，Helicopter…：

public abstract class Vehicle {

    abstract Something doStuff(...);

    abstract SomethingElse doOtherStuff(...);

    abstract Foo bar(...);

}

public class MotorizedVehicle extends Vehicle {

    @Override
    Something doStuff(...) {
        return new Something();
    }

    @Override
    SomethingElse doOtherStuff(...) {
        return new SomethingElse();
    }

    @Override
    Foo bar(...) {
        return new Foo();
    }

}

public class FlyingMotorizedVehicle extends MotorizedVehicle {

    @Override
    SomethingElse doOtherStuff(...) {
        return new SomethingElse();
    }

}

public class Airplane extends FlyingMotorizedVehicle  {

    @Override
    Foo bar(...) {
        //do something different
        return new Foo();
    }

}

public class Helicopter extends FlyingMotorizedVehicle {

    @Override
    Foo bar(...) {
        //do something totally different
        return new Foo();
    }

}
[...]

Vehicle提供抽象方法的抽象类也是如此。MotorizedVehicle是Vehicle其方法的具体实现的子类。FlyingMotorizedVehicle还是MotorizedVehicle重写MotorizedVehicles方法子集的实现的子类。

现在有子类Helicopter，Airplane并且可能还有其他一些子类，在示例中，这些子类覆盖了的具体实现MotorizedVehicle#bar(...)。我想要的是“强制”其的每个子类MotorizedVehicle都必须重写该bar(...)方法并提供其自己的实现。

是否可以FlyingMotorizedVehicle通过以下方式进行更改：

public class FlyingMotorizedVehicle extends MotorizedVehicle {

    @Override
    SomethingElse doOtherStuff(...) {
        return new SomethingElse();
    }

    abstract Foo bar(...);

}

这样我就重新定义了bar(...)as抽象方法？我的IDE并没有抱怨它，但这当然并不意味着它会真正起作用。

希望您能理解我在这里指出的内容。

提前致谢

模糊的