inheritance - 为什么 Dart 不继承构造函数？

Question

我来自 PHP 世界，很好奇为什么开发人员选择不向继承添加构造函数(带有 arg)的方式。在我看来，它根据结构重复了大量代码，这违反了 DRY 原则。我做了很少的研究——PHP、Ruby、Python 继承了构造函数。 Java、C#、C++ 不是。 C++0x 具有显式定义继承的新功能。

那么程序员没有继承构造函数并一次又一次地显式编写构造函数有什么好处吗？

Answer 1

我对梅森的解释并不完全满意，所以我做了一些研究。

我发现语言设计者选择省略构造函数继承有两个关键原因，我可以更好地理解它们。

第一个原因是版本控制——如果在基类中引入了新的构造函数，或者如果在基类中更改了构造函数签名，子类将继承这些更改，这可能会导致不可预测的副作用。

这个问题经常出现在各种类型的框架中，其中框架 API 的一部分通常由您希望扩展的类或供您实现的抽象类组成 - 如果框架类中的构造函数签名发生变化，您将继承这些更改，这在大多数情况下是没有意义的。这被称为“Fragile Base Class”问题。

第二个原因更多是在哲学方面，与第一个原因密切相关。当您构造一个实例时，构造函数定义您的类对您的要求，作为该类的使用者 - 所以它是关于类本身的需求。将此与定义类的实际行为的方法进行对比 - 它是关于类的作用。基于此，哲学论点是，继承是关于行为，而不是关于需求。

这两个论点实际上是同一事物的两个方面:可以说，构造函数继承是脆弱的，因为构造函数定义了类的需求——例如，期望基类的作者能够预测所有需求是不合理的你的扩展类(class)。

或者，至少，做出这种假设(如某些语言所做的那样)会大大限制基类的有用性，因为您只能在扩展类中引入新行为，而不能引入任何新需求。

我想到的另一件事是完整性的问题——这是个人偏好的问题，但在继承构造函数的语言中，我经常发现你必须通过基类进行大量挖掘才能学习和理解所有给定类的实例可能以不同的方式构造。

如果构造函数不能被继承，这将迫使任何类的作者明确地说明预期构造类的实例的所有方式——即使这些构造函数中的一些将是完全微不足道的，事实上它们是在类本身中定义的，表明该类的作者确实认为它们很有用，并且必须理解和考虑基类的所有需求，基类可能是由不同的作者编写的。

与盲目继承基类的需求相反，没有主动展示基类的需求是否与扩展类的需求一致。

在实践中，我发现需求不一致。但即使当它们对齐时，被迫考虑它们如何对齐，会导致更高的代码质量，我相信这就是语言设计者选择非继承构造函数的哲学——毕竟，语言只有一样好作为写入其中的代码。