首页 > 代码库 > 读书笔记—CLR via C#章节8-10

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

前言

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

构造函数

  • 抽象类默认的构造函数可访问为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