问试图逐个案例地禁止重写是错误的吗？

EN

我的意见通常是否定的。

原因是，即使你能以某种方式使你的FlyingCar的行为只会像它是一辆汽车从这一点上，它仍然是已经在上操作，就好像它是一辆FlyingCar，并可能不再是一个有效的状态为汽车。

也许你的图形引擎不能显示FlyingCar的原因是因为它使用的纹理。但是已经有人在它上面调用了一个load_appropriate_textures方法，这个方法已经在里面存储了它的纹理数据。将FlyingCar更改为汽车会改变再次调用load_appropriate_textures时发生的情况，但FlyingCar不会覆盖render_car方法，它只是将数据放在render_car可以找到的地方。因此，您组织中的其他一些糟糕的程序员将最终尝试调试为什么汽车无法渲染，并显示一些关于FlyingCar纹理的错误消息。

也许在这个特殊的案例中不会发生这种情况。但这是可能的。有人可以在以后修改Car和FlyingCar，从而引入这种问题。

一般来说，对于FlyingCar“就好像”它是一辆汽车，你真的必须再次重复所有的初始化(和后续的修改)。重复后来的修改通常是不可能的(因为它们没有被记录下来)，并且重复初始化只意味着构造一辆新车。

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

真的，听起来FlyingCar需要具备禁用其飞行功能的功能。像这样的东西总是很难在事后固定下来。

您可以使用composition instead of inheritance (听起来您的Car对象无论如何都需要重构为更小的类：the Car object is huge)。

然后，Car对象可以包含一个组件，该组件使其具有飞行功能。要禁用汽车的飞行能力，您只需临时(或永久，如果需要)从Car对象中移除飞行组件。

通常，当我们创建一个FlyingCar时，我们会确保以一种正确工作的方式扩展Car。希望我们只依赖Car的接口，Car承诺保持不变；如果我们还依赖于Car中的其他代码，我们这样做是因为我们拥有这些代码。

另一方面，这在相反的方向上不起作用。当有人试图将FlyingCar改装成汽车时，无论用户多么小心，都不能保证它不会坏掉。毕竟，FlyingCar只是承诺，如果按原样使用，它将表现为汽车的变体；而不是说，在有人试图从它身上取出一些部件后，它将表现得像汽车一样。

例如，FlyingCar可能在构造时修改了各种控件的函数。如果它的方法被禁用了，它就不会变成汽车；它只会坏掉。