试图根据具体情况抑制覆盖是错误的吗？ [关闭]

我明白为什么通过方法重写实现的多态性非常有用。我问的是，在某些情况下，当多态对象作为参数被接收时（而不是在定义其类时！），尝试抑制它可能会出现什么问题（如果有的话）。

Car 类描述了汽车的行为。 FlyingCar 类描述了可以变形和飞行的汽车的行为。

我从某处收到 Car 类或其子类的对象。我无法控制他们传递给我的东西。

我知道由于我的图形引擎的技术限制，我无法显示飞行汽车。或者也许我希望玩家在不使用飞行能力的情况下完成特定任务。因此，我想简单地禁用汽车的飞行能力，使其看起来像是 Car 类的对象。我在想使用向下转型 https://stackoverflow.com/questions/8886159/can-overriding-of-a-method-be-prevented-by-downcasting-to-a-superclass，但似乎行不通。

这也许是不可能的，但如果我找到一种方法用我使用的语言来做到这一点，这是不是糟糕的设计？如果是这样，为什么，还有什么替代方案？

我无法使用复制构造函数之类的东西从我收到的类创建 Car 类的对象，因为所有数据的复制成本太高（Car 对象很大）。

Thanks!

EDIT:

我想避免在这个问题中选择特定的语言。一旦我选择了一种语言，答案很可能是“这在技术上是不可能的”，或者“这是可能的，但所需的黑客太危险了”，等等。

我想了解这是否是一个糟糕的设计，其原因与某种语言（无法）支持它的能力无关。

我的意见通常是否定的。

原因是，即使你能以某种方式让你的 FlyingCar 的行为就像从现在开始它是一辆汽车一样，它仍然已经已进行手术就好像它是一辆 FlyingCar，并且可能不再处于汽车的有效状态。

也许您的图形引擎无法显示 FlyingCar 的原因是它使用的纹理。但已经有人叫了load_appropriate_textures方法，它已将纹理数据存储在其中。如果你打电话，将 FlyingCar 变成汽车将会改变发生的事情load_appropriate_textures再次，但 FlyingCar 不会覆盖render_car方法，它只是将数据放在哪里render_car会找到它。因此，您组织中的其他一些糟糕的程序员最终只会尝试调试汽车无法渲染的原因，并显示一些有关 FlyingCar 纹理的错误消息。

也许在这一特殊情况下不会发生这种情况。但它可以。有人可以稍后以引入此类问题的方式修改 Car 和 FlyingCar。

一般来说，对于 FlyingCar“就像”它是一辆汽车一样，您确实必须再次重复所有初始化（以及后续修改）。重复以后的修改通常是不可能的（因为它们没有被记录），并且重复初始化只不过意味着构造一辆新车。

所以“总的来说”这似乎是一个坏主意。在任何特定情况下，如果您能找到一种方法来做到这一点，也许您会认为它是可以接受的。程序员每天都会做出妥协，这种情况时有发生。但是，如果不可能完全通用地做到这一点，那么您总是会面临这样的风险：稍后会对 Car 和/或 FlyingCar 进行完全合理的更改，从而使您的 hack 不再起作用。

确实，听起来 FlyingCar 需要具有禁用其飞行功能的功能。这样的事情事后总是很难再坚持下去。