Abstract Class Design: Why not define public constructores?
请看这里(抽象类设计)：http://msdn.microsoft.com/en-us/library/ms229047.aspx
它说：
(1)不要在抽象类型中定义公共或受保护的内部(Visual Basic中受保护的友元)构造函数。
在C中，我们无法实例化抽象类。那么，在C中为抽象类定义公共构造函数仍然重要吗？或者不是因为语义的原因而为抽象类编写公共构造函数？
它还说：
(2)在抽象类中定义一个受保护的或内部的构造函数。
定义内部构造函数？？在(1)中，它告诉我们，不定义内部受保护的构造函数是因为"具有公共或受保护内部可见性的构造函数适用于可以实例化的类型"。为抽象类定义内部构造函数是否违反了(1)中的规则？
事先谢谢。：)
让我们看看每一个案例。
推荐：受保护——最明显的情况是——所有子类都可以调用构造函数，不管它们驻留在哪个程序集中(只要抽象基类本身对它们可见)。
内部-当您希望抽象类型公开可见，但不公开继承时很有用。在这种情况下，您将希望使所有非私有构造函数都为
internal 。只有与抽象基类在同一程序集中的子类才能调用构造函数——实际上，只有子类才能继承。另一个用例是，如果您想要一个只对同一个程序集子类可见的"特殊"构造函数。private-主要用于"脏工作"构造函数，在使用构造函数链接时，抽象类的其他构造函数将其作为目标。当所有构造函数都是私有的时，唯一的其他用途是只允许嵌套类进行子类化，嵌套类确实可以访问包含类型的私有成员。
不推荐：
公共-不有用，行为与
protected 相同。因为基类是抽象的，所以只有子类才能调用构造函数。内部保护-这也与
protected 没有区别。protected internal 可访问级别是指受保护或内部，不受保护和内部。但是，这里的internal 修饰符没有作用——它不阻止位于程序集外部的子类调用构造函数(假设抽象基类是公共的)，因为它们可以依赖protected 访问，也不允许非子类的相同程序集类型调用它(类型是抽象的)。
这里的关键点是，抽象类中的每个非
几年过去了。我想我现在对这个问题有了更好的理解。所以我想在ANI出色的答案之外再增加一些输入。
In C#, we are not able to instantiate an abstract class. So, does it
still matter to define public constructors for abstract classes in C#
?
它对编译器没有影响，但对代码阅读器有影响。抽象类型中的公共构造函数会误导代码阅读器(它们可能认为它们可以被实例化)。
Define internal constructors ?? In (1), it tells us that not defining
internal protected constructors is because that"Constructors with
public or protected internal visibility are for types that can be
instantiated". Doesn't defining internal constructors for abstract
classes break the rules in (1) ?
如果我们希望抽象类只能由同一程序集中的子类继承，显然我们不能使用
公开-如上所述，
public 会误导代码阅读器。不要使用它。private-我们希望抽象类可以由同一程序集中的子类继承，而不仅仅是由嵌套的子类继承，因此
private 将不起作用。内部保护-我们永远不需要它，因为它和
protected 没什么不同。内部——这对代码阅读器有误导性，但我们别无选择。我认为这是一种权衡。
n c，我们无法实例化抽象类。那么，在C中为抽象类定义公共构造函数仍然重要吗？是否为抽象类编写公共构造函数是因为语义的原因？
确切地。您不希望用户看到一个可访问的构造函数，但是当他们调用它时，会得到一个编译错误。
定义内部构造函数？？在(1)中，它告诉我们，不定义内部受保护的构造函数是因为"具有公共或受保护内部可见性的构造函数适用于可以实例化的类型"。为抽象类定义内部构造函数是否违反了(1)中的规则？
我认为规则1是关于