为什么有一个具体类的抽象子类是糟糕的设计？

Question

毕竟，任何java抽象都是Object的抽象子类。有时我们需要强制子类实现一些方法，但可能已经有了一个定义得很好的层次结构和具体的类。

例如:我有一个运行良好的层次结构，Vehicle<- Car

现在，我想将ElectricCar添加到此层次结构中。

vehicle<--Car<--电动汽车。

我还希望所有不同类型的电动汽车都能实现特定的行为，比如getBatteryLife或其他什么-

为什么让ElectricCar抽象化是个坏主意？

Answer 1

把它抽象一点也没有错。如果你的业务需要你让它变得抽象，这是可以的。就像你说的，Java lib中的很多类都是抽象的，并且仍然在扩展对象。

Answer 2

就其本身而言，这还不错。不常见，但也不坏。我能想到的唯一一件事是可理解性:如果我看到一个可以实例化的具体类汽车，我通常会假设它的任何子类也是可实例化的，因为99%的代码都能在这个way.Then上工作，有那么一秒钟，我会因为不能实例化ElectricCar而感到困惑。

Answer 3

可以说，这种模式破坏了Liskov Substituion Principle，因为如果声明为抽象，则不能在需要"Car“的地方传递" ElectricCar”(当然，您可以传递ElectricCar子类的实例)。

在这个特定的例子中，具体的电动汽车(氢动力/插电式/等等？)我希望直接从"Car“继承，因为它们满足"is-a”关系，并且是"Car“的适当特化。如果您想描述它们应该提供的一些常见行为和特征，那么它们还应该实现一个ElectricCar接口。

看起来你真正想要的是从Car继承的能力(因为这就是它们)，和共享/重用电动汽车相关方法的通用实现。在本例中，您看到的是多重继承问题或对mixins的需求，而这两者在Java语言中都不受直接支持。

在具体的层次结构中间提供一个抽象类可能是绕过这一点的一种方法，但它并不美观。