Sealed与Final修饰符其实并不是一个语言平台的产物,他们有着各自所属的语言环境,但这两个关键字都是.Net平台中不可或缺的,那么二者用法几何,随本文一探究竟。

一.Sealed

sealed 修饰符可以应用于类、实例方法和属性。用于类时,该类被称为密封类,密封类不能被继承;用于方法时,该方法被称为密封方法,密封方法会重写基类中的方法;sealed修饰符应用于方法或属性时,必须始终与override一起使用;结构是隐式密封的,因此它们不能被继承。

● 描述方法:

//Error: cannot be sealed because it is not an override
    public sealed string func()
    {
      return "";
    }

//OK

public sealed override string func()
    {
      return "";
    }

● 继承中的方法:(TestChild2中无法重写任何方法)

C#中的Sealed和J#中的Final比较(转载)-LMLPHP

●描述属性:

public sealed override double Hours
    {
       get { return 0.1; }
       set { }
    }

●描述变量:

//Error The modifier 'sealed' is not valid for this item
    sealed override string a;

●描述接口:

interface Itesta
    {
      //Error cannot be sealed because it is not an override
      sealed string Geta();
    }

● sealed能提高性能优化?

有一些朋友认为当元素被标记为sealed时,有助于系统运行性能的提升,其理由有2:

1有助于JIT内联。

2消除了协变与逆变和后期绑定,使CLR直接执行这个实例。

这看似是有些道理的,可这样做又会提升多少性能,提升性能的同时又损失了什么呢?

先说说“第1点”,促使JIT内联代码的因素有很多,JIT不会因为一个类是sealed,就去装入其中的内容(详见.Net Discovery 系列之六--深入浅出.Net实时编译机制(下),这也不符合程序局部性原理。http://www.cnblogs.com/isline/archive/2009/12/27/1633453.html),而对于sealed类内部方法的内联,很大原因也是由于方法槽映射关系决定的,sealed作用有待考证。

第2点,由于sealed类不可派生或被继承,所以的确在运行时省去可CLR一些额外的工作,但是这些工作只是一些类似于“寻址”的工作,因为虚拟方法表已经完成了运行时与编译时的对应关系,纯粹的运行时只是在寻找这些关系而已,所以sealed省去的只是一部分较为复杂的寻址关系,因为即使没有继承,也不可避免一个方法表的应用。

而这样做又损失了什么呢?大家想想,面向对象的原因是什么?是提升性能吗?显然不是,面向对象的只是高级语言层面的,最终运行的代码都是以顺序流程的方式出现,面向对象的本质是“抽象”,它解决的是软件产品的“控制”问题,变不可控为可控,变不可预测的风险为可预测的风险,所以如果因为要提升性能,而把大部分类都sealed化,岂不是大大削弱了面向对象的抽象能力呢?

● Sealed不能同时abstract?

也许在高级语言中抽象须实现与密封不可继承是一对矛盾者,但IL暴露了一些不一样的细节,让我们来分析一下这段IL代码:

C#中的Sealed和J#中的Final比较(转载)-LMLPHP

这段代码简单得很,就是声明了一个类,然而这个类却是abstract和Sealed的,猜猜这个类用了什么修饰符修饰它?

好吧,其实高级语言中对应的修饰符就是static。

C#中的Sealed和J#中的Final比较(转载)-LMLPHP

static类不能被实例化(abstract)亦不可派生(Sealed),我想abstract同时Sealed也未尝不可,但这样做会使语义出现二义性,为避免这种效果才规定在编辑器中不可abstract+Sealed,static修饰类的初衷我想也是如此,实际上static在修饰类时,就是一个包含了实现的abstract+Sealed的类,这个类不能被实例化也不能派生出新的类。

二.Final

final修饰符来限定变量、字段、方法和类。用于变量时,该变量只能赋值一次,不可修改;用于方法时,该方法不能被重写或隐藏;用于类时,该类不能被继承。

接口的成员是不能使用该关键字的,道理和不能在abstract类使用final一样。

值得一提的是,如果使用final修饰类中的字段,那么该字段必须在构造函数中赋值,否则使用类实例调用的方式是无法对该字段进行赋值的,道理很简单,类在实例化时,会为每一个成员字段赋初值,之后你如果再通过实例方式调用该final字段,就属于二次赋值的情况了,这种情况是不允许的。在构造函数中为final变量赋值的方法叫做“延时赋值”(Java),相应的final变量叫做“空白final”(Java)。

Final并不是一个C#中的关键字,但经常在C#面试题中出现,例如说说“Final、Finally、finalize的区别”,其实这已经超出C#的范畴,这三个关键字分别考核了J#、.Net 容错方法、.Net垃圾收集机制,奇怪的是,每次我面试C#程序人员时,大部分人员对Final这个关键字并无陌生之感,相反却答得头头是道,看来来面试之前,早在网上有所预习,呵呵。

例子(摘自MSDN,已做翻译):

public class Value

{

public int i = 1;

}

public class FinalData

{

//可认为等同于编译时常量

final int i1 = 9;

static final int i2 = 99;

//public 常量:

public static final int i3 = 999;

//不可作为编译时常量:

final int i4 = (int)(Math.random() * 11);

static final int i5 = (int)(Math.random() * 11);

Value v1 = new Value();

final Value v2 = new Value();

static final Value v3 = new Value();

// 数组:

final int[] a = { 1, 2, 3, 4, 5, 6 };

public void print(String id)

{

System.out.println(id + ": " + "i4 = " + i4 + ", i5 = " + i5);

}

public static void main(String[] args)

{

FinalData fd1 = new FinalData();

// Error: Can't change value! (i1被描述为fianl的)

// fd1.i1++;

// OK. Object isn't constant(虽然v2是fianl的,但其中的变量并不受此约束)

fd1.v2.i++;

// OK. Not final.

fd1.v1 = new Value();

for (int i = 0; i < fd1.a.length; i++)

{

fd1.a[i]++; // OK. Object isn't constant.(与上面那个v2一样,数组是final的,但数组元素不受约束)

}

// Error: Can't change handle! (v2是final的)

// fd1.v2 = new Value();

// Error: Can't change handle! (v3是static final的,等同于常量)

// fd1.v3 = new Value();

// Error: Can't change handle!(数组本身是final,不可new)

// fd1.a = new int[3];

fd1.print("fd1");

System.out.println("Creating new FinalData");

FinalData fd2 = new FinalData();

fd1.print("fd1");

fd2.print("fd2");

}

}

答案:

-------------------------------------------------河蟹的分割线-------------------------------------------------------

fd1: i4 = 0, i5 = 7

Creating new FinalData

fd1: i4 = 0, i5 = 7

fd2: i4 = 8, i5 = 7

总结:final是J#中的一种修饰符,在VS2008及以后版本中就放弃J#了,它与sealed不同的是fianl可以修饰变量,而sealed则不能,不过你可以通过readonly关键字来实现。

关于二者对性能的提升作用,我认为有待考证,从理论层面来讲,为难以证明的性能因素而特意使用此关键字有些得不偿失。

-------------------------------------------------------------------------------------------------------------------

注:本文转载于:http://www.cnblogs.com/isline/archive/2010/08/31/1813396.html,感谢原文作者!

05-07 15:29