看这里（抽象类设计）：http://msdn.microsoft.com/en-us/library/ms229047.aspx
上面写着：
(1) 不要在抽象类型中定义公共或受保护的内部（Visual Basic 中的受保护朋友）构造函数。
在 C# 中，我们无法实例化抽象类。那么，在 C# 中为抽象类定义公共构造函数是否仍然重要？还是因为语义原因不为抽象类编写公共构造函数？
它还说：
(2) 请务必在抽象类中定义受保护或内部构造函数。
定义内部构造函数 ??在 (1) 中，它告诉我们不定义内部受保护构造函数是因为“具有公共或受保护内部可见性的构造函数适用于可以实例化的类型”。为抽象类定义内部构造函数不违反（1）中的规则吗？
提前致谢。 :)
【问题讨论】：
标签： c# .net abstract-class design-guidelines
让我们来看看每个案例。
protected - 最明显的情况 - 所有子类都可以调用构造函数，无论它们驻留在哪个程序集中（只要抽象基类本身 em> 对他们可见）。
internal - 当您希望抽象类型公开可见，但不公开可继承 时很有用。在这种情况下，您需要将所有非私有构造函数设为internal。只有与抽象基类相同 程序集中的子类才能调用构造函数——实际上，只有它们能够继承。另一个用例是，如果您想要一个“特殊”构造函数，它应该只对相同程序集的子类可见。
private - 主要用于抽象类的其他构造函数在使用构造函数链接时作为目标的“脏工作”构造函数。当所有构造函数都是私有的时，唯一的其他用途是只允许嵌套类的子类化，这些类确实可以访问包含类型的私有成员。
public - 没用，与protected 的行为相同。无论如何，只有子类可以调用构造函数，因为基类是抽象的。
受保护的内部 - 这也与protected 没有什么不同。 protected internal 可访问性级别表示受保护的 OR 内部，而不是受保护的 AND 内部。但是，这里的 internal 修饰符没有任何作用 - 它不会阻止位于程序集之外的子类调用构造函数（假设抽象基类是公共的），因为它们可以依赖 @987654326 @访问，也不允许不是子类的同程序集类型调用它（类型是抽象的）。
这里的关键是抽象类中的每个非private 构造函数都充其量是protected。 vanilla internal-modifier 加强了对谁可以调用构造函数的限制。 public 和 protected internal 没有完成任何事情，因为它们似乎削弱了限制，但实际上并没有成功。
【讨论】：
n C#，我们无法实例化抽象类。那么，在 C# 中为抽象类定义公共构造函数是否仍然重要？或者不为抽象类编写公共构造函数是因为语义？
没错。您不希望用户看到可访问的构造函数，但是当他们调用它时，会出现编译错误。
定义内部构造函数 ??在 (1) 中，它告诉我们不定义内部受保护构造函数是因为“具有公共或受保护内部可见性的构造函数适用于可以实例化的类型”。为抽象类定义内部构造函数不违反（1）中的规则吗？
我相信规则 1 是关于 public 和 protected internal 规则 2 是关于 protected 和 internal。所以两者之间没有交集。
【讨论】：
几年过去了。我想我现在对这个问题有了更好的理解。因此，除了 Ani 的出色回答之外，我还想补充一些意见。
在 C# 中，我们无法实例化抽象类。那么，行吗 在 C# 中为抽象类定义公共构造函数仍然很重要 ?
这对编译器无关紧要，但对代码阅读器却很重要。抽象类型中的公共构造函数对代码阅读者误导（他们可能认为它们可以被实例化）。
定义内部构造函数 ??在（1）中，它告诉我们没有定义 内部受保护的构造函数是因为“构造函数具有 公共或受保护的内部可见性适用于可以 实例化”。不为抽象定义内部构造函数 类违反了 (1) 中的规则？
如果我们希望抽象类只能被同一个程序集中的子类继承，显然我们不能使用protected（否则它可以在程序集之外被继承）。现在我们有一些选项可供选择：
public - 如上所述，public 对代码阅读器有误导。不要使用它。
private - 我们希望抽象类可以被同一程序集中的子类继承，而不仅仅是嵌套子类，因此private 将不起作用。
受保护的内部 - 我们永远不需要它，因为它与 protected 没有什么不同。
内部 - 这对代码阅读器误导，但我们别无选择。我认为这是一个权衡。
【讨论】：