抽象类设计:为什么不定义公共建筑？

Question

看这里(抽象类设计)：http://msdn.microsoft.com/en-us/library/ms229047.aspx

上面写着：

(1)不以抽象类型定义公共或受保护的内部构造函数( Visual中的受保护朋友)。

在C#中，我们无法实例化抽象类。那么，在C#中为抽象类定义公共构造函数仍然重要吗？还是因为语义的原因而不为抽象类编写公共构造函数？

它还说：

(2)在抽象类中确实定义了受保护的或内部的构造函数.

定义内部构造器?？在(1)中，它告诉我们，不定义内部受保护的构造函数是因为“具有公共或受保护内部可见性的构造函数用于可以实例化的类型”。定义抽象类的内部构造函数是否违反了(1)中的规则？

提前谢谢。:)

Answer 1

让我们来看看每一个案例。

推荐：

• protected --最明显的情况--所有子类都可以调用构造函数，而不管它们驻留在哪个程序集中(只要抽象基类本身对them).
• internal是可见的)--当您希望抽象类型公开可见，但不能公开继承时，就很有用。在本例中，您希望使所有非私有构造函数internal。只有与抽象基类相同的程序集中的子类才能有效地调用构造函数，只有它们才能继承。另一个用例是，如果您想要一个“特殊”构造函数，该构造函数应该只对相同的程序集subclasses.
• private可见--主要用于抽象类的其他构造函数在使用构造函数链接时所针对的“脏-工作”构造函数。当所有构造函数都是私有的时，唯一的其他用途是只允许嵌套类进行子类化，这些类确实可以访问containing-type.

的私有成员。

不建议：

• public --没有用，行为与protected相同。无论如何，只有子类才能调用构造函数，因为基类是abstract.
• protected内部--这与protected也没有什么不同。protected internal可访问性级别意味着保护或内部，而不是保护和内部。但是，此处的internal修饰符没有任何用途--它不阻止驻留在程序集中之外的子类调用构造函数(假设抽象基类是公共的)，因为它们可以依赖protected访问，也不允许非子类的相同程序集类型调用它(类型是抽象的)。

这里的关键点是，抽象类中的每个非private构造函数都最好是protected。普通的internal-modifier加强了对谁可以调用构造函数的限制。public和protected internal没有完成任何事情，因为它们似乎削弱了限制，但并没有真正做到这一点。

Answer 2

N C#，我们无法实例化抽象类。那么，在C#中为抽象类定义公共构造函数仍然重要吗？或者不为抽象类编写公共构造函数是因为语义的原因？

一点儿没错。您不希望用户看到一个可访问的构造函数，但是当他们调用它时，会得到一个编译错误。

定义内部构造器?？在(1)中，它告诉我们，不定义内部受保护的构造函数是因为“具有公共或受保护内部可见性的构造函数用于可以实例化的类型”。定义抽象类的内部构造函数是否违反了(1)中的规则？

我相信规则1是关于public的，protected internal规则2是关于protected和internal的。所以两者之间没有交集。

Answer 3

几年过去了。我想我现在对这个问题有了更好的理解。因此，除了Ani的优秀答案之外，我还想添加一些更多的输入。

在C#中，我们无法实例化抽象类。那么，在C#中为抽象类定义公共构造函数仍然重要吗？

对于编译器来说，这并不重要，但对代码读取器来说确实很重要。抽象类型中的公共构造函数对代码阅读器来说是误导(他们可能认为可以实例化)。

定义内部构造函数？在(1)中，它告诉我们，不定义内部受保护的构造函数是因为“具有公共或受保护内部可见性的构造函数用于可以实例化的类型”。定义抽象类的内部构造函数是否违反了(1)中的规则？

如果我们希望抽象类只能由同一个程序集中的子类继承，那么显然我们不能使用protected (否则它可以在程序集之外继承)。现在我们有一些选择：

• public -正如上面提到的，public对代码阅读器来说是误导的。不要使用it.
• private --我们希望抽象类可以由同一程序集中的子类继承，而不仅仅是由嵌套的子类继承，因此private不会使用work.
• protected内部--因为它与protected.
• internal没有什么不同--这是误导来编写阅读器的，但我们没有其他选择。我觉得这是个trade-off.