什么时候用sealed？
我知道sealed的作用，当修饰类时让一个类不能被继承，当修饰虚方法时派生类不能再覆盖它。
我知道sealed的好处，就是CLR查方法表变快了。

但是我不知道，什么时候使用sealed。不论我以上说的对不对，我想要至少以下问题的回答。

比如说，我一个类写好了，一个虚方法抽象方法都没有，且仅用于我的项目，且尚未被继承，有没有必要用sealed修饰类？
还有一个类，有虚方法，但仅用于我的项目，且尚未被继承，有没有必要用sealed修饰类？
我从WinForm或WPF创建自定义控件或元素，覆盖了基类的虚方法MeasureCore。该控件只用于我的项目，且尚未被继承，有没有必要用sealed修饰MeasureCore方法？有没有必要用sealed修饰该类？
更甚者，已知WinForm或WPF的控件提供了众多的虚方法，我创建的自定义控件覆盖并密封所有基类的虚方法，有意义吗？
------最佳解决方案--------------------
密封类可以防止被篡改，重写其中的成员，使效果符合预期；
同时用sealed修饰的类效率上来说稍微比非sealed高，因为减少了编译器的检验。
比如咱们的静态类在元数据中就是抽象密封类；
咱们的String，Thread都是密封的..你说他们为什么需要密封自然就明白了。
------其他解决方案--------------------
LZ你的思路不对 当你开发的是架构，而不是具体业务实现的时候。你就知道sealed该怎么用了
------其他解决方案--------------------

引用:

LZ你的思路不对 当你开发的是架构，而不是具体业务实现的时候。你就知道sealed该怎么用了

对，我开发的是具体业务实现，所以我不要去碰sealed？就是所有类或方法都保持unsealed？还是一概sealed？
------其他解决方案--------------------
只要你不想让类被继承的时候，使用Sealed，否则不需要。

我好想一次都没有用过。。。。。
------其他解决方案--------------------
给你一个建议：以测试为准，而不是理论。

当你对东西的测试写到自己都厌烦的时候，框架就快出来了。不是单纯靠玩儿理论，不是杯弓蛇影杞人忧天，而是实践能改变人的思路。
------其他解决方案--------------------
 还真没用过。也只在静态类的il里见过
------其他解决方案--------------------

引用:

给你一个建议：以测试为准，而不是理论。

当你对东西的测试写到自己都厌烦的时候，框架就快出来了。不是单纯靠玩儿理论，不是杯弓蛇影杞人忧天，而是实践能改变人的思路。

说的真好
------其他解决方案--------------------
做图形软件设计的时候,我们一般允许圆角矩形,矩形,从基本的base图元继承,不希望别人做圆角矩形等从矩形继承开发,那么我们在设计矩形图元的时候,将其设置为sealed的,那么,其他人在开发圆角矩形的时候则只能从base图元继承,不能从矩形图元.通过合理的规则,避免一些问题的发生.
------其他解决方案--------------------
是啊,如果仅仅是你自己在使用,无所谓了。如果你的开发是为别人使用的，那有些限定是才必要的。
------其他解决方案--------------------

引用:

是啊,如果仅仅是你自己在使用,无所谓了。如果你的开发是为别人使用的，那有些限定是才必要的。

行。那默认是sealed还是unsealed？

默认sealed，等到我发现这个类需要被继承时，去掉sealed关键字。
默认unsealed，等到我那天有兴致了，发现没有任何类继承她，就加上sealed关键字。
------其他解决方案--------------------
我也没用过sealed
------其他解决方案--------------------
默认unsealed,不只是sealed，就算是其他的修饰也是如此，如果你仅仅为了满足自己需要而使用可以不必考虑太多，如果是为了别人使用，那就的使用这些修饰特性。当然如果从一个良好的变成习惯角度来说，应该对各种访问修饰善加利用。
------其他解决方案--------------------
想保护自己的类，不被人盗用篡改，就用sealed，微软底层的类多数是sealed，这意味着你无法直接继承并重写它的核心类。
------其他解决方案--------------------

引用:

同时用sealed修饰的类效率上来说稍微比非sealed高

这才是我要的。。尽管你没有给出来源。