为什么我们不能从ADO.NET中的数据提供程序类（例如SqlConnection，SqlCommand）继承？
这背后有什么原因吗？
答案 0 :(得分：0)
我正在从链接中重新发布内容，以回答@Damien_The_Unbeliever提供的内容可能会下降，特别是考虑到它是由Eric Lippert编写的。
为什么要密封这么多框架类？
2004年2月1日3分钟朗读
我在本月初讨论了有关子类化的一些问题，
并建议密封您的课程。 Joel On Software读者问道
为什么Microsoft在框架中提供了很多密封类。
张贴者说：“我还没有看到有关其原因的合理解释
这种方式的灵活性有限。 “好吧，如果可能的话，我的团队制作的每个公开课都会被密封。
如果无法密封某个班级，那么如果可能的话，它会带有
继承要求，这样只有MSFT私有的人
键可以将其子类化。我坚持这项政策的理由不成立
归结为一项首要原则：
好的代码完全可以完成它的设计工作，不多也不少。
让我通过四种方式对此进行扩展。
哲学上的。 OOP设计包含子类来表示
多态“是”两件事之间的关系。长颈鹿就是
弄乱是哺乳动物，是动物...除非我能想到一个清晰的
客户需要与
表示IS A关系的情况 我产生的一些代码，我不允许这种情况。
实用。设计类，以便可以有效地
由第三方扩展的是HARD。 （查看收藏基地
类。）您必须正确设计-什么是
受保护？您必须正确实施该设计。测试
矩阵的增长极大，因为您必须考虑什么奇怪的事情
人们要做的事情。您必须记录受保护的
方法并编写有关如何正确地将其分类的文档。
这都是昂贵且费时的-这就是我们可以节省的时间
花费更多时间在更重要的用户场景中寻找错误，
规划将来的版本，修复安全漏洞，无论如何。有
我们只能花有限的开发时间来进行设计和
实施代码，因此我们必须以有益的方式使用它
客户最多。如果该类不是为了扩展而设计的，那么我要
通过密封来避免所有这些费用。我不会释放
半熟的类，看起来可扩展，但实际上不是很
那里。
兼容。如果将来发现我应该盖上
上课，我被卡住了。密封班级是一个重大变化。如果发现
我本来应该离开班级的，以后再开班的
版本是不间断的更改。密封类有助于维护
兼容性。
确保安全。多态的全部要点是您可以绕过
看起来像动物但实际上是长颈鹿的物体。有
这里潜在的安全问题。
每次实现一个采用
实例的方法时 非密封类型，面对
，您必须将该方法编写为健壮的 该类型的潜在敌对实例。你不能依靠任何
您知道对您的实现正确的不变量，因为
某些敌对的网页可能会将您的实现子类化，请覆盖
虚拟方法来做会弄乱您的逻辑并将其传递的东西
每次密封一个类时，我都可以编写使用该类的方法
我有信心知道那堂课是做什么的。
现在，我认识到开发人员是高度实践的人，他们只是
想把事情做好。能够扩展任何类都很方便，
当然。典型的开发人员说“ IS-A-SHMIZ-A，我只想拍一个
成为Froboznicator类的“ Confusticator”。开发人员可以
编写一个哈希表以将一个映射到另一个，但随后必须
担心什么时候去掉物品，等等，等等-不是火箭
科学，但这是工作。
显然这里需要权衡。权衡在于让
开发人员允许他们处理任何旧对象，从而节省了一些时间
一方面作为财产包，然后开发出精心设计的
OOPtacular，功能齐全，健壮，安全，可预测，可测试
在合理的时间内构建框架-我要精益求精
严重地倾向于后者。因为你知道吗？那些
如果我们提供的框架，开发人员将苦苦抱怨
他们放慢了速度，因为它半生不熟，易碎，不安全且
没有完全测试！