在另一个论坛上，我遇到了关于使用构造函数的一些基本案例的论点，我记得在某个地方读过，在类自己的沙箱之外禁止代码来调用该类的构造函数，这将被认为是一个很好的设计。该参数与调用定义为接受可变数量的参数的超类构造函数有关，而有问题的特定语言通常不允许执行构造函数。
我不记得是谁以及在何种场合，但我觉得这是一些尊重的来源，但是，我的记忆可能会背叛我。除了语言细节之外，这作为一种元语言的良好实践是否有意义，或者这只是一个制定规则/过于个人化而不是一般推荐？
以下是我能想到的一些理由：
无论语言如何，初始化顺序通常都存在问题，这通常是创建对象所特有的，外部代码可能不会意识到这些特性/暴露这些特性可能会被视为泄漏细节对象的实现。
构造函数内部的错误导致语言无法进行自动内存管理。让外部代码管理此类错误几乎可以保证故障/内存泄漏。
继承通常要求我们都能够从超类引用子类（匿名，例如，通过调用抽象方法 - 考虑Java，这是有问题的）和返回（不一定是匿名的）。即如果一个超类在其字段上调用一个函数，我们可能需要将这些字段预先初始化为子类中的某些其他值，当然，我们可能需要在子类中使用超类初始化的乘积。这可能需要在构造函数中使用“钩子”，但是如果我们将“裸”构造函数暴露给外部代码（因为外部代码可能通过在约定之外工作而影响对象创建），那么这将是不可能的。正在初始化和何时。
答案 0 :(得分：0)
您所指的通常称为静态工厂方法，是直接调用构造函数的替代方法。这是否是好的设计取决于用例。
通常首选调用构造函数，因为它是创建对象的自然方式，但是在许多情况下首选工厂方法。 MSDN上的这篇文章很好地总结了何时使用其中一个：Factories vs. Constructors
我认为我没有遇到你提到的超类论点。