读书笔记—CLR via C#章节8-10
2014-10-21 21:10 周信达 阅读(216) 评论(0) 编辑 收藏 举报前言
这本书这几年零零散散读过两三遍了，作为经典书籍，应该重复读反复读，既然我现在开始写博了，我也准备把以前觉得经典的好书重读细读一遍，并且将笔记整理到博客中，好记性不如烂笔头，同时也在写的过程中也可以加深自己理解的深度，当然同时也和技术社区的朋友们共享
构造函数
- 抽象类默认的构造函数可访问为protected，普通类默认为public
- 派生类默认调用一个基类构造器（如果没有无参构造器，则需要显式调用）
- 不通过构造函数创建对象？
- 静态方法Object.MemberwiseClone，分配内存复制字节
- 运行时序列化
- 不要在构造器中调用会影响所构造对象的任何虚方法，如果虚方法重写，导致无法预测的行为
- 这一点，在java中尤其明显，因为java的内联初始化是在基类初始化之后
- 基类构造函数虚方法指向子类实现，可是子类并没有完全初始化完成，想象一下！
- 构造实例初始化顺序
- 内联初始化（这一点和java不一样）
- 调用基类的构造器
- 调用构造器自己的代码
- 值类型的构造器
- 值类型总是提供默认构造器，所以总是可以实例化
- 由于总是有默认构造器，值类型不允许使用内联初始化语法
- 开发人员无法定义值类型的无参构造器，只能定义带参构造器
- 基于栈的值类型字段都必须在读取之前写入（赋值），并且时全部字段。否则编译出错
- 值类型在构造器中可以给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编译器在调试代码时不会内联属性方法，方便调试
- 发布版本中，经过内联优化，可能比较快
