标签：系统 运行环境 一般来说 toolbar 组件 数据 方向 泛型 block
四十五、尽量减少装箱拆箱
四十六、为应用程序创建专门的异常类
四十七、使用强异常安全保证
四十八、尽量使用安全的代码
四十九、实现与 CLS 兼容的程序集
五十、实现小尺寸、高内聚的程序集
这是该系列的最后一篇。也许有些理论有可能会过时，我想它仍有存在的必要，人的知识水平也是一个不断成长的过程，学会站在前人的肩膀上，尝试不断的借鉴与总结。
值类型是数据的容器，不支持多态。
装箱把一个值类型放在一个未确定类型的引用对象中，让该值作为引用类型所使用。拆箱指从引用类型的位置取出值的一个副本。
装箱和拆箱会在无意中创建许多副本，导致许多难以发现的 Bug。
使用接口而不是使用类型可以避免装箱，即将值类型从接口实现，然后通过接口调用成员。
装箱拆箱都是比较影响性能的手段，应该尽可能的避免装拆箱操作。
泛型可以避免装拆箱操作。
值类型装箱是隐式的，难以发现，需要自己多加注意。
这里是一篇较为详细的关于装拆箱的博文：《装箱与拆箱》。
1.只有当用户会以不同的形式去处理错误时，才应该创建不同的异常类。
2.自定义的异常类应该以“Exception”结尾，并且继承 System.Exception 或其他异常类。不过你也需要适当地包含该基类中的构造函数，内容直接交给基类实现即可。
/// <summary>
/// 自定义的异常类
/// </summary>
public class MyException : Exception
{
public MyException() : base()
{
}
public MyException(string s) : base(s)
{
}
public MyException(string s, Exception e) : base(s, e)
{
}
protected MyException(SerializationInfo info, StreamingContext cxt) : base(info, cxt)
{
}
}
3.在抛出自定义的异常时，应该将原始的异常存放在 InnerException 属性中，这样就可以显示足够友好，并且信息丰富的异常：
public void Do()
{
try
{
//DoException();
}
catch (DoException e)
{
var msg = $"该问题是博主故意引起的";
throw new MyException(msg, e);
}
}
4.只有在存在不同类型的恢复操作时，才应该抛出不同类型的异常，定义异常类时，还要提供基类中支持的所有构造函数。此外，不要忘记使用 InnerException 属性来保存低层次的异常信息。
1.Dave Abrahams 定义了 3 种安全异常来保证程序：基础保证、强保证，以及无抛出保证。
2.强异常保证：从异常中恢复和简化异常处理之间提供了一个平衡点，如果一个操作因为某个异常中断，程序将维持原状态不变，操作要么彻底完成，要么就不会修改程序的任何状态。强异常保证的好处：任何时候若是捕获了异常，所有将要尝试的正常操作都不继续进行。程序当前的状态如尚未开始进行该操作一样。
3.对将要修改的数据做防御性的复制，对这些数据的防御性复制进行修改，这中间的操作可能会引发异常，在出现异常时可将临时副本和原对象进行交换。
4.终结器、Dispose() 方法和委托对象所绑定的目标方法在任何情况下都应当确保他们不会抛出异常。
.NET 运行时可以保证一些怀有恶意的代码不能直接渗透到远程计算机上执行。
CLR 中的带有代码的访问安全设置，如：CLR 强制要求基于角色的安全认证，这样才能判断某些代码能否在基于一个特定的角色账号下运行。
CLR 可以检查 IL 代码，确保它不存在潜在的危险行为。如：直接访问原始内存。
如果代码不需要任何的安全权限，就不需要使用 CAS 的 API 来判断访问权限，因为这样只会影响性能，额外增加 CLR 的工作量。
你可以使用 CAS 的 API 来访问一些受保护的资源，一般需要额外的权限。如非托管的内存和文件系统、注册表等。
一般来说，我们编写的 C# 代码都是安全的，除非你使用了 /unsafe。
应该尽可能地避免访问非托管内存。确实有需要的话，应该将其隔离在独立的程序集中。
1..NET 运行环境与语言无关，我们创建的程序集必须与 CLS 保持兼容，这样才能保证其他的开发人员可以用另一种语言来调用你的组件。
如果我们都将所有的代码放在一个程序集中，这不利于组件的重用，也不利于系统的局部更新，若是可以将其拆分成小程序集，以组件的形式进行重用，就可以从一定程度上简化后续的开发工作。
我们用类进行功能的封装和数据的存储，只有公有的类、结构和接口才应该称为契约，被其它用户（或程序集）进行访问。
建议将程序拆分成多个程序集，把相关的类型放在同一个程序集中。
一个程序集应该是一个包含相关功能的，具有良好组织的一个库。如果不知道怎样的颗粒度最好，可以略微向小而多的方向倾斜。
如果所有参数和返回值都是接口，那么任何一个程序集都可以很容易地用另一个实现了相同接口的程序集进行代替。
更小的程序集同样可以降低程序启动时的开销。更大的程序集要花上更多的 CPU 时间来加载，且需要更多的时间来将必须的 IL 编译成机器指令。虽然只有启动时将被调用的代码会被 JIT 编译，但程序集是整体载入的。
在跨越程序集时，安全性检查会成为一个额外的开销。程序跨越程序集的次数越小，其执行效率越高。
性能的损耗对我们来说可以忽略不计，因为在开发时，我们着重的是代码的灵活度，所以不需要担心将大程序集拆分成小程序集的性能问题。
常见的程序集：小且仅专注于某个特定功能的程序集，大一些但包含通用功能的程序集。无论何种情况，都应该保证其尽可能合理的小，但不应该过度。
《Effective C#》快速笔记（一）- C# 语言习惯
《Effective C#》快速笔记（二）- .NET 资源托管
《Effective C#》快速笔记（三）- 使用 C# 表达设计
《Effective C#》快速笔记（五） - C# 中的动态编程
《Effective C#》快速笔记（六） - C# 高效编程要点补充
《Effective C#》快速笔记 - C# 高效编程要点补充
标签：系统 运行环境 一般来说 toolbar 组件 数据 方向 泛型 block
原文地址：http://www.cnblogs.com/MuNet/p/6902537.html
