为什么具体类的抽象子类是糟糕的设计？
毕竟任何java抽象都是Object的抽象子类。有时我们需要强制子类实现一些方法，但可能已经有了一个定义良好的带有具体类的层次结构。
例如：我有一个运作良好的层次结构 Vehicle<--- Car
，现在我想将 ElectricCar 添加到此层次结构中。
车辆<--汽车<--电动汽车。
我还希望所有不同类型的电动汽车都能实现某些行为，例如 getBatteryLife 或其他行为 -
为什么将 ElectricCar 抽象化是一个坏主意？
After all ANY java abstract is an abstract subclass of Object. Sometimes we need to force the subclass to implement some methods, but may already have a pretty well defined hierarchy with concrete classes.
For example: I have a well functioning hierarchy with
Vehicle<--- Car
and now I want to add ElectricCar to this hierarchy.
vehicle<--Car<--ElectricCar.
I also want all the different types of electric cars to implement certain behaviors like getBatteryLife or something-
Why would it be a bad idea to make ElectricCar abstract ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
让它变得抽象并没有什么错。如果您的业务要求您将其抽象化，那也可以。正如你所说，Java lib 中的许多类都是抽象的，并且仍在扩展 Object。
there's nothing wrong in making it abstract. if your business requires you to make it abstract, it's fine. Like you said, lots of classes in Java lib are abstract and still extending Object.
就其本身而言，这还不错。不常见，但也不错。我唯一能想到的是可理解性：如果我看到一个可以实例化的具体类 Car，我通常会假设它的任何子类也是可实例化的，因为 99% 的代码都是这样工作的。然后我会感到困惑暂时无法实例化 ElectricCar。
It's not bad, per se. Not common, but not bad. The only thing I can think of is understandability: if I saw a concrete class Car that I could instantiate, I would normally assume that any child of it was also instantiable, because 99% of code works this way.Then I'd be confused, for a second, about not being able to instantiate an ElectricCar.
可以说，这种模式违反了里氏替换原则，因为你无法通过“ElectricCar”如果将“Car”声明为抽象，则在任何需要“Car”的地方（当然，您可以传递 ElectricCar 子类的实例）。
在这个特定的例子中，具体的电动汽车（氢动力/插入式/等等？）我希望直接从“汽车”继承，因为它们满足“is-a”关系并且是“汽车”的适当专业化。如果您想描述他们应该提供的一些常见行为和特征，那么他们还应该实现 ElectricCar 接口。
看来您真正想要的是能够从 Car 继承（因为它们就是这样）并共享/重用电动汽车相关方法的常见实现。在这种情况下，您正在考虑多重继承问题或需要 mixins，这两者都不是Java 直接支持。
在具体层次结构中间提供一个抽象类可能是解决这个问题的一种方法，但它并不漂亮。
It could be argued that this pattern breaks the Liskov Substituion Principle since you can't pass "ElectricCar" wherever "Car" is expected if it's declared abstract (you could pass instances of ElectricCar subclasses of course).
In this particular example, the concrete electric cars (hydrogen powered/plug-in/etc?) I would expect to inherit directly from "Car" since they satisfy an "is-a" relationship and are a proper specialisation of "Car". If you wanted to described some common behaviours and traits they should provide then they should also implement an ElectricCar interface.
It seems what you really want is the ability to inherit from Car (since that is what they are) and share/re-use common implementations of electric car related methods. In this case you are looking at a multiple inheritance problem or a need for mixins, neither of which are directly supported in Java.
Providing an abstract class in the middle of a concrete hierarchy may be one way around this, but it's not pretty.
就我个人而言，我更愿意为 ElectricCar 定义一个接口，然后允许实现类定义方法。然后你可以通过另一种机制来共享 getBatteryLife 的行为。
我已经建立了一些相当深的继承层次结构，并且我倾向于避免它们随着时间的推移而形成的脆弱性质。一个基类可能有意义，但我会考虑如何构建对象模型以在可能的情况下共享行为而无需继承。
Personally I would prefer to define an Interface for ElectricCar and then allow the implementing class to define the methods. Then you can share the behavior of getBatteryLife through another mechanism.
I've built some pretty deep hierarchies of Inheritance and I tend to avoid them do to the brittle nature they tend to build up over time. One Base class might make sense, but I would think about how you can compose your object model to share behavior w/o inheritance if possible.
在你的例子中，我想说的是，按理说
Car类也应该是抽象的（或接口）。但ElectricCar是抽象的并没有什么问题。In you example I would say that supposedly the
Carclass should be abstract (or an interface), too. But there is nothing wrong with theElectricCarbeing abstract.