这是我在这里问到的另一个问题的后续问题:最后 从同一个类中的其他构造函数调用构造函数
前一个是关于如何,现在问题是为什么微软这样设计它？
更新:我的问题是:
为什么我不能直接在另一个构造函数的结尾处调用构造函数,而我可以在开始时调用它.
如果他们最后禁止打电话他们为什么不禁止在开头直接打电话呢？
为什么我不能直接在另一个构造函数的结尾处调用构造函数,而我可以在开始时调用它.
好吧,让我们将其分解为两种情况.(1)你正在调用一个"this"构造函数,(2)你正在调用一个"基础"构造函数.
假设你是第一种情况.这种情况的典型使用模式是让一堆ctors采用不同的参数然后全部"反馈"到一个完成所有实际工作的主ctor(通常是私有的).通常情况下,公共银行没有自己的机构,因此在空座之前"之前"或"之后"之间调用另一个ctor没有区别.
假设您处于第一种情况并且您正在每个ctor中工作,并且您希望在当前ctor开始之外的其他时间呼叫其他ctors.
在这种情况下,您可以通过将不同ctors完成的工作提取到方法中,然后以您喜欢的顺序调用ctors中的方法来轻松完成此操作.这比发明一种允许你在任意位置调用其他ctors的语法更胜一筹.有许多设计原则支持这一决定.两个是:
1)有两种方法可以做同样的事情会造成混乱; 它增加了心理成本.我们在C#中经常有两种方法可以做同样的事情,但在这种情况下,我们希望通过两种不同的方式来完成这项工作,使每种情况都很有吸引力,有趣且强大的功能具有明显的专业性,利弊.(例如,"查询理解"与"流畅查询"是构建查询的两种截然不同的方式.)有办法以你调用任何其他方法的方式调用ctor似乎有两种方法可以做某事 - 调用初始化方法 - 但没有引人注目或有趣的"收益".
2)我们必须添加新的语言语法来完成它.新语法的成本非常高; 它必须经过设计,实施,测试和记录 - 这些都是我们的成本.但是你的成本更高,因为你必须了解语法的含义,否则你无法阅读或维护其他人的代码.那是另一个成本; 再次,如果我们认为对我们的客户有明确,引人注目的巨大利益,我们只需要花费大量费用来添加语法.我没有看到这里的巨大好处.
简而言之,在不添加功能的情况下轻松实现所需的施工控制流程,并且添加该功能没有任何令人信服的好处.没有新的有趣的代表能力被添加到该语言.
对于"基础"场景,它非常简单.您永远不想在派生构造函数之后调用基础构造函数.这是正常依赖规则的反转.派生代码应该能够依赖于已经设置了对象的"基本"状态的基础构造函数; 基本ctor永远不应该依赖于已经设置派生状态的派生构造函数.