为什么要使用密封类？该怎么处理
为什么要使用密封类？？？？？？
我知道一个类如果不想被继承 可是使用sealed 修饰符 变成一个密封类
可是我想知道
1.为什么要使用密封类？？
2.什么情况向 必须使用密封类？？
3.不使用密封类不是也可以吗？？？那为什么还要使用密封类？？？？
------解决思路----------------------
主要是为了不想被继承而设计的。在class前面用sealed修饰，代表私有的。
------解决思路----------------------
既然你都知道密闭类的作用,那为何你还提问题1,没是什么情况必须要用,如果我的类提供给你用但又不希望你通过继承来扩展我的类那就有用了...
------解决思路----------------------
个人观点：这属于微软的一个“过度设计”。我从来没用到过。作用就是：在class前面加上sealed以后，这个类将无法被继承。没有什么情况必须使用密封类，这个关键字可有可无。
------解决思路----------------------
没有做过架构设计，没有到这个层次 估计很难理解
------解决思路----------------------
那java的密封类呢？java也过度设计？
------解决思路----------------------
保护知识产权
------解决思路----------------------
密封类的优点
1.版本控制: 如果类最开始就是密封的, 那么将来可以在不破坏兼容性的前提下改为非密封类
2.性能有一定的提升: 如果调用密封类的虚方法, 编译器可以生成更高效的代码
3.安全性和可预测性
缺点:密封类限制了类的派生, 对开发人员造成不便
clr via c#
------解决思路----------------------
为了说清楚你这个问题，我得打很多字。。。
当你设计一个类，并且在设计的时候就确定不希望将来有人（或者你自己）因为凌乱的继承关系，使这个类的最初动机变得扑朔迷离的时候，可以将这个类sealed（为什么要不希望自己继承这个类后做改动？因为你的脑袋并不是电脑，你的记性并不是那么好，最初的设计初衷，在以后系统越来越庞大的时候，你可能自己都忘了自己当初设计的这个类可能考虑到的某些很细微的因素，这个因素要求你将来不要改变这个类的成员或者任何属性），当你有个基类A，然后有个类B继承A，然后类C又继承B，类D又继承类C的时候，你可能会发生凌乱。这个时候，有些类在设计之初你就可以将它sealed，以确保将来在某一个时刻脑袋短路的情况想把这个类继承出一个子类来改写的时候，编译器就会报错提示你，“唤起”你的记忆。
比如.net中，你可能没注意到过，struct也是sealed的，你不能继承一个struct。另外，.net framework中还有一些成员都是静态类型的类，比如Pen和Brushes也是sealed的，因为画笔和画刷在设计之初都已经定义好了它都有哪些颜色，并且不希望将来改变画笔和画笔的这些属性，所以直接给它sealed掉。
另外，如果你的程序中有用到反射的话，CLR对用了sealed关键字的类和属性会比普通的类有一点性能上的提升。因为反射需要找回某个类的属性，没有继承关系的类，它的“关系网”不复杂，CLR能够很轻易地定位它的“位置”。
sealed还可以用于限制类成员方法等。
比如你有一个类A包含了一个vitual虚方法FOO1，另外一个类B继承了A，并且还有另外一个类C继承了类B，在这种情况下，类C可以跳过类B而直接从类A override 方法 FOO1，而不管类B是否override了方法FOO1，这个时候很容易发生凌乱。你的设计结构很有可能拎不清了。
什么时候用sealed关键字？事实上，所有的类在设计之初，你都可以设计为sealed，直到你将来在设计别的类的时候，确定需要从这个类有继承关系，因为任何类sealed以后，你还可以将它unsealed（直接以掉sealed关键字）。
另外，在一些类含有一些安全方面考虑的成员或者属性，不希望被别的类继承或者改变的时候，可以设计为sealed。
总而言之，言而总之，sealed关键字有一部分用途比如CLR反射时候性能方面的优化，但是最主要的目的应该是为了帮助开发人员尽量避免在设计和编程的过程人为的犯错，让你在连续加班48个小时后保持清晰的思路记得你当初设计的某个不希望被继承改动的类的目的而不犯错，要求是不是太高了！所以，微软的天才们设计了这个关键字，帮助了大家一把，让这个需要注意和提醒的事情，交给了CLR和编译器。
------解决思路----------------------
简单点说，设你定义了一个抽象类用来建模 四边形
有两个派生类，一个是长方形，一个是正方形
那么对于长方形和正方形来说，如果再往下继承来说，就一点意义也没有了，因为不可能再出现另外一种四边形。
------解决思路----------------------
别的不说，我举一个例子，大家很多人都会用static class。这个static其实就是 abstract+sealed。
我需要澄清一点，sealed是CLR和IL层面的东西，和“设计”关系不大。
就好比你可以认为一种高级语言没有必要用到goto，但是如果你设计一个虚拟机，跳转是必须考虑的东西。
------解决思路----------------------
个人观点，简单说：他应该是为了保证原则问题的，例如：一个工厂生产“牙刷”，我只希望出现普通的，而不是两个刷头或者多个手柄的。
------解决思路----------------------
你平时根本无需使用它，除非必须使用。
比如说当我们突然发现从mongodb中反序列化出来的对象实际上无法正常地得到子类对象，而都是仅仅得到了父类对象，而你以前不知道、没注意，现在出现乱子了。你已经没有时间去补充测试所有代码了，你需要在24小时内就发布产品，那么就可以把父类变为sealed的并删除子类，这样调试器就能告诉你哪些代码是出乱子的，而不需要你一点点地去学测试代码。然后当你已经发布了产品，如果你觉得懒得再把子类写回来了，懒得实现原来的既定扩展目标，你根本没有压力需要对类型进行扩展，那么你当然仍然会保留着这个sealed。
正常的情况下，我们没有必要在设计一个class时就去杞人忧天地去担心“要不要写sealed”关键字的问题。按照正常的面向对象初级方式，你就无需写上它！
------解决思路----------------------
有人说“继承是危险的啊，所以千万不要写继承啊，要用一大堆垃圾组合代码来代替继承啊”的时候，那是15年前某本java早期“xx模式”书上的论调。如果说一个人写下了class，它就是制造思维混乱的，那么为什么现在这个时代里的程序员都普遍地使用OOPL语言了，而不是像那本书写作的那个年代时那样大多数程序员都没有接触过OOPL语言呢？时过境迁，我们不要抱着10年前就已经跟不上时代的“xx模式”的书里边的只言片语。
说到struct为什么不支持继承，那么你要看看struct有什么行为再说。不是说人家微软的语言设计师“喜欢struct不被继承”于是这样设计了，而是因为struct的操作要模拟传统的c、pascal、汇编语言程序中的struct相同的行为（例如赋值语句的处理仅仅是简单的按字节拷贝操作），而继承了之后还能够模拟吗？
------解决思路----------------------
密封类 VS 普通类
密封类：到他这一代已经最牛逼了，不需要生孩子来扩展天赋了。
普通类：造物者觉得他还可以通过生孩子来扩展家族天赋。
------解决思路----------------------
我基本同意你说的。我之所以说“过度设计”，只是这个关键字对于我日常工作而言没有太大意义，所以我说是“个人观点”。本来么，凡事没有绝对。
------解决思路----------------------
楼主的问题MSDN给出了详细明确的答复:
通过密封类限制扩展性
具体的应用实例还是可以看看微软.net的代码,其中有大量的密封类,比如:ADO.net中的SqlDataAdapter 类
------解决思路----------------------
就像道教中的三清一样，他们是永远不死的，所以你永远不可能给他来扩展一个死亡的方法，为了防止别人会这么操作，你就要加这个关键字了。
------解决思路----------------------
最明确的就是为了预防一些因继承可能会导致的异常
我知道一个类如果不想被继承 可是使用sealed 修饰符 变成一个密封类
可是我想知道
1.为什么要使用密封类？？
2.什么情况向 必须使用密封类？？
3.不使用密封类不是也可以吗？？？那为什么还要使用密封类？？？？
------解决思路----------------------
主要是为了不想被继承而设计的。在class前面用sealed修饰，代表私有的。
------解决思路----------------------
既然你都知道密闭类的作用,那为何你还提问题1,没是什么情况必须要用,如果我的类提供给你用但又不希望你通过继承来扩展我的类那就有用了...
------解决思路----------------------
个人观点：这属于微软的一个“过度设计”。我从来没用到过。作用就是：在class前面加上sealed以后，这个类将无法被继承。没有什么情况必须使用密封类，这个关键字可有可无。
------解决思路----------------------
没有做过架构设计，没有到这个层次 估计很难理解
------解决思路----------------------
那java的密封类呢？java也过度设计？
------解决思路----------------------
保护知识产权
------解决思路----------------------
密封类的优点
1.版本控制: 如果类最开始就是密封的, 那么将来可以在不破坏兼容性的前提下改为非密封类
2.性能有一定的提升: 如果调用密封类的虚方法, 编译器可以生成更高效的代码
3.安全性和可预测性
缺点:密封类限制了类的派生, 对开发人员造成不便
clr via c#
------解决思路----------------------
为了说清楚你这个问题，我得打很多字。。。
当你设计一个类，并且在设计的时候就确定不希望将来有人（或者你自己）因为凌乱的继承关系，使这个类的最初动机变得扑朔迷离的时候，可以将这个类sealed（为什么要不希望自己继承这个类后做改动？因为你的脑袋并不是电脑，你的记性并不是那么好，最初的设计初衷，在以后系统越来越庞大的时候，你可能自己都忘了自己当初设计的这个类可能考虑到的某些很细微的因素，这个因素要求你将来不要改变这个类的成员或者任何属性），当你有个基类A，然后有个类B继承A，然后类C又继承B，类D又继承类C的时候，你可能会发生凌乱。这个时候，有些类在设计之初你就可以将它sealed，以确保将来在某一个时刻脑袋短路的情况想把这个类继承出一个子类来改写的时候，编译器就会报错提示你，“唤起”你的记忆。
比如.net中，你可能没注意到过，struct也是sealed的，你不能继承一个struct。另外，.net framework中还有一些成员都是静态类型的类，比如Pen和Brushes也是sealed的，因为画笔和画刷在设计之初都已经定义好了它都有哪些颜色，并且不希望将来改变画笔和画笔的这些属性，所以直接给它sealed掉。
另外，如果你的程序中有用到反射的话，CLR对用了sealed关键字的类和属性会比普通的类有一点性能上的提升。因为反射需要找回某个类的属性，没有继承关系的类，它的“关系网”不复杂，CLR能够很轻易地定位它的“位置”。
sealed还可以用于限制类成员方法等。
比如你有一个类A包含了一个vitual虚方法FOO1，另外一个类B继承了A，并且还有另外一个类C继承了类B，在这种情况下，类C可以跳过类B而直接从类A override 方法 FOO1，而不管类B是否override了方法FOO1，这个时候很容易发生凌乱。你的设计结构很有可能拎不清了。
什么时候用sealed关键字？事实上，所有的类在设计之初，你都可以设计为sealed，直到你将来在设计别的类的时候，确定需要从这个类有继承关系，因为任何类sealed以后，你还可以将它unsealed（直接以掉sealed关键字）。
另外，在一些类含有一些安全方面考虑的成员或者属性，不希望被别的类继承或者改变的时候，可以设计为sealed。
总而言之，言而总之，sealed关键字有一部分用途比如CLR反射时候性能方面的优化，但是最主要的目的应该是为了帮助开发人员尽量避免在设计和编程的过程人为的犯错，让你在连续加班48个小时后保持清晰的思路记得你当初设计的某个不希望被继承改动的类的目的而不犯错，要求是不是太高了！所以，微软的天才们设计了这个关键字，帮助了大家一把，让这个需要注意和提醒的事情，交给了CLR和编译器。
------解决思路----------------------
简单点说，设你定义了一个抽象类用来建模 四边形
有两个派生类，一个是长方形，一个是正方形
那么对于长方形和正方形来说，如果再往下继承来说，就一点意义也没有了，因为不可能再出现另外一种四边形。
------解决思路----------------------
别的不说，我举一个例子，大家很多人都会用static class。这个static其实就是 abstract+sealed。
我需要澄清一点，sealed是CLR和IL层面的东西，和“设计”关系不大。
就好比你可以认为一种高级语言没有必要用到goto，但是如果你设计一个虚拟机，跳转是必须考虑的东西。
------解决思路----------------------
个人观点，简单说：他应该是为了保证原则问题的，例如：一个工厂生产“牙刷”，我只希望出现普通的，而不是两个刷头或者多个手柄的。
------解决思路----------------------
你平时根本无需使用它，除非必须使用。
比如说当我们突然发现从mongodb中反序列化出来的对象实际上无法正常地得到子类对象，而都是仅仅得到了父类对象，而你以前不知道、没注意，现在出现乱子了。你已经没有时间去补充测试所有代码了，你需要在24小时内就发布产品，那么就可以把父类变为sealed的并删除子类，这样调试器就能告诉你哪些代码是出乱子的，而不需要你一点点地去学测试代码。然后当你已经发布了产品，如果你觉得懒得再把子类写回来了，懒得实现原来的既定扩展目标，你根本没有压力需要对类型进行扩展，那么你当然仍然会保留着这个sealed。
正常的情况下，我们没有必要在设计一个class时就去杞人忧天地去担心“要不要写sealed”关键字的问题。按照正常的面向对象初级方式，你就无需写上它！
------解决思路----------------------
有人说“继承是危险的啊，所以千万不要写继承啊，要用一大堆垃圾组合代码来代替继承啊”的时候，那是15年前某本java早期“xx模式”书上的论调。如果说一个人写下了class，它就是制造思维混乱的，那么为什么现在这个时代里的程序员都普遍地使用OOPL语言了，而不是像那本书写作的那个年代时那样大多数程序员都没有接触过OOPL语言呢？时过境迁，我们不要抱着10年前就已经跟不上时代的“xx模式”的书里边的只言片语。
说到struct为什么不支持继承，那么你要看看struct有什么行为再说。不是说人家微软的语言设计师“喜欢struct不被继承”于是这样设计了，而是因为struct的操作要模拟传统的c、pascal、汇编语言程序中的struct相同的行为（例如赋值语句的处理仅仅是简单的按字节拷贝操作），而继承了之后还能够模拟吗？
------解决思路----------------------
密封类 VS 普通类
密封类：到他这一代已经最牛逼了，不需要生孩子来扩展天赋了。
普通类：造物者觉得他还可以通过生孩子来扩展家族天赋。
------解决思路----------------------
我基本同意你说的。我之所以说“过度设计”，只是这个关键字对于我日常工作而言没有太大意义，所以我说是“个人观点”。本来么，凡事没有绝对。
------解决思路----------------------
楼主的问题MSDN给出了详细明确的答复:
通过密封类限制扩展性
具体的应用实例还是可以看看微软.net的代码,其中有大量的密封类,比如:ADO.net中的SqlDataAdapter 类
------解决思路----------------------
就像道教中的三清一样，他们是永远不死的，所以你永远不可能给他来扩展一个死亡的方法，为了防止别人会这么操作，你就要加这个关键字了。
------解决思路----------------------
最明确的就是为了预防一些因继承可能会导致的异常