前言

这本书这几年零零散散读过两三遍了，作为经典书籍，应该重复读反复读，既然我现在开始写博了，我也准备把以前觉得经典的好书重读细读一遍，并且将笔记整理到博客中，好记性不如烂笔头，同时也在写的过程中也可以加深自己理解的深度，当然同时也和技术社区的朋友们共享

构造函数

• 抽象类默认的构造函数可访问为protected，普通类默认为public
• 派生类默认调用一个基类构造器（如果没有无参构造器，则需要显式调用）
• 不通过构造函数创建对象？
• 静态方法Object.MemberwiseClone，分配内存复制字节
• 运行时序列化
• 不要在构造器中调用会影响所构造对象的任何虚方法，如果虚方法重写，导致无法预测的行为
• 这一点，在java中尤其明显，因为java的内联初始化是在基类初始化之后
• 基类构造函数虚方法指向子类实现，可是子类并没有完全初始化完成，想象一下！
• 构造实例初始化顺序
1. 内联初始化（这一点和java不一样）
2. 调用基类的构造器
3. 调用构造器自己的代码
• 值类型的构造器
• 值类型总是提供默认构造器，所以总是可以实例化
• 由于总是有默认构造器，值类型不允许使用内联初始化语法
• 开发人员无法定义值类型的无参构造器，只能定义带参构造器
• 基于栈的值类型字段都必须在读取之前写入（赋值），并且时全部字段。否则编译出错
• 值类型在构造器中可以给this赋值，而引用类型的this则时只读的
• 类型构造器（静态构造函数）
• static并且强制可访问性为private
• 一个AppDomain中只会执行一次，并且线程安全，适合单例模式
• 值类型中可以定义类型构造器，但是永远不要这么做，为什么呢？
• 手动调用类型构造器 RuntimeHelpers.RunClassConstructor方法
• 构造器应该避免循环依赖
• 值类型不允许使用实例字段的内联初始化，但是静态字段却可以，DateTime就是典型！
• 静态析构器Finalize不存在，只能通过AppDomain.DomainUnload事件进行登记回调

类型构造器的性能考量

• 时机的不确定性
• 访问类的非继承字段或成员前 precise精确语义，时机精确
• 访问静态字段或静态实例\实例方法前或者实例构造器之前，before-field-init语义
• 字段初始化前语义时机不确定，因为CLR保证访问成员前运行静态构造器
• 如果没有显式定义类型构造器，则静态字段使用beforefieldinit标记，否则不使用此标记
• beforefieldinit可以优化调用，但是precise不可以精确调用
• 静态字段只要在访问之前初始化就可以了，时机无所谓。而显式类型构造器可能包含具有副作用的代码，所以需要精确拿捏运行的时机

属性

• 有参属性和无参属性，静态、实例、抽象和虚属性
• 自动属性的缺点
• 初始化默认值
• 序列化
• 调试的支持
• 属性或索引器不可以作为out或ref参数传递
• DateTime.Now是一个错误的设计，为什么？

Tips

• 转型表达式会促使生成代码调用显式转换操作符方法。如果使用as或is，则永远不会调用这些方法
• 引用参数
• 引用参数 out 无须初始化、方法内不能读取参数值、必须写入  ref 必须初始化、方法内可以读取或写入
• 引用传值，可以避免复制字节，提升执行效率
• 引用传值ref和out可以应用于构造函数噢！
• 建议：参数尽量使用弱类型参数（比如接口或抽象类），返回值最好使用强类型
• 自动集合初始化器，编译器针对对象调用Add方法，否则编译出错
• 代码内联
• 是指将一个方法的代码直接编译到调用它的方法当中
• 避免在运行时发出调用所产生的开销
• JIT编译器在调试代码时不会内联属性方法，方便调试
• 发布版本中，经过内联优化，可能比较快

读书笔记—CLR via C#章节8-10