謎題

在C#中，用virtual關(guān)鍵字修飾的方法（屬性、事件）稱(chēng)為虛方法（屬性、事件），表示該方法可以由派生類(lèi)重寫(xiě)（override）。虛方法是.NET中的重要概念，可以說(shuō)在某種程度上，虛方法使得多態(tài)成為可能。

然而虛方法的使用卻存在著很大學(xué)問(wèn)，如果濫用的話勢(shì)必對(duì)程序產(chǎn)生很大的負(fù)面影響。比如下面這個(gè)例子：

public class Puzzle
{
  public Puzzle()
  {
    Name = "Virtual member call in constructor";
    Solve();
  }

  public virtual string Name { get; set; }

  public virtual void Solve()
  {
  }
}

如果您的Visual Studio沒(méi)有安裝ReSharper，那么上面的代碼不會(huì)有任何異常。但如果安裝了，在構(gòu)造函數(shù)內(nèi)部給Name賦值和調(diào)用Solve時(shí)就會(huì)在下面產(chǎn)生一個(gè)波浪線，即警告：virtual member call in constructor。

這是什么原因呢？我們?cè)跇?gòu)造函數(shù)中調(diào)用虛方法，礙著ReSharper什么事兒了？

其實(shí)這個(gè)警告就是提醒我們不要在非封閉類(lèi)型的構(gòu)造函數(shù)內(nèi)調(diào)用虛方法或虛屬性。但為什么這樣做不合適呢？在解惑之前，我們先來(lái)了解兩個(gè)概念。

類(lèi)型的初始化順序

我們先來(lái)看這樣一段代碼：

class Base
{
  public Base()
  {
    Console.WriteLine("Base constructor");
  }
}
class Derived : Base
{
  public Derived()
  {
    Console.WriteLine("Derived constructor");
  }
}
static class Program
{
  static void Main()
  {
    new Derived();
    Console.Read();
  }
}

猜一猜它的輸出結(jié)果是什么？

你也許已經(jīng)猜到了，它的結(jié)果是：

Base constructor
Derived constructor

我們?cè)诔跏蓟粋€(gè)對(duì)象時(shí)，總是會(huì)先執(zhí)行基類(lèi)的構(gòu)造函數(shù)，然后再執(zhí)行子類(lèi)的構(gòu)造函數(shù)。

虛方法調(diào)用

我們?cè)賮?lái)看一段代碼：

class Base
{
  public void M()
  {
    Console.WriteLine("Base.M");
  }

  public virtual void V()
  {
    Console.WriteLine("Base.V");
  }
}
class Derived : Base
{
  public new void M()
  {
    Console.WriteLine("Derived.M");
  }

  public override void V()
  {
    Console.WriteLine("Derived.V");
  }
}
static class Program
{
  static void Main()
  {
    var d = new Derived();
    Base b = d;
    b.M();
    b.V();
    d.M();
    d.V();
    Console.Read();
  }
}

再來(lái)猜一猜輸出結(jié)果吧。

貌似應(yīng)該是：

Base.M
Base.V
Derived.M
Derived.V

但運(yùn)行一下會(huì)發(fā)現(xiàn)，真正的結(jié)果是這樣的：

Base.M
Derived.V
Derived.M
Derived.V

這是為什么呢？

原來(lái)對(duì)于非虛方法調(diào)用，編譯器會(huì)進(jìn)行一些額外的“動(dòng)作”。比如找出所調(diào)用對(duì)象的實(shí)際類(lèi)型，以訪問(wèn)正確的方法表（調(diào)用b.V()的時(shí)候就會(huì)找到變量b的實(shí)際類(lèi)型Derived，從而輸出Derived.V）。

解惑

現(xiàn)在回到我們最初的謎題，virtual member call in constructor。結(jié)合以上兩個(gè)知識(shí)點(diǎn)，會(huì)有哪些發(fā)現(xiàn)？

我們稍微改造一下虛方法調(diào)用的那個(gè)例子。

class Foo
{
  public Foo(string s)
  {
    Console.WriteLine(s);
  }
  public void Bar() { }
}

class Base
{
  public Base()
  {
    V(); // Virtual member call in constructor
  }
  public virtual void V()
  {
    Console.WriteLine("Base.V");
  }
}
class Derived : Base
{
  private Foo foo;
  public Derived()
  {
    foo = new Foo("foo in Derived");
  }

  public override void V()
  {
    Console.WriteLine("Derived.V");
    foo.Bar(); // will throw NullReferenceException
  }
}

在Base的構(gòu)造函數(shù)中調(diào)用虛方法V()時(shí)，ReSharper會(huì)給出virtual member call in constructor的警告。這是因?yàn)閂可以在Base的任意子類(lèi)中被改寫(xiě)（override），而這種改寫(xiě)，很有可能使得它依賴(lài)于自己的構(gòu)造函數(shù)，如上例所示。而由于之前提到的類(lèi)型初始化順序，在執(zhí)行Base b = new Derived();這樣的代碼時(shí)，Base的構(gòu)造函數(shù)要早于Derived的構(gòu)造函數(shù)執(zhí)行，因此在執(zhí)行到foo.Bar()時(shí)foo還是個(gè)空引用。

明白了嗎？我們來(lái)簡(jiǎn)單總結(jié)一下。Virtual member call in constructor的警告是因?yàn)椋瑢?duì)于Base b = new Derived();這樣的代碼：

1. 基類(lèi)構(gòu)造函數(shù)的執(zhí)行要早于子類(lèi)構(gòu)造函數(shù)
2. 基類(lèi)構(gòu)造函數(shù)中對(duì)于虛方法的調(diào)用，實(shí)際調(diào)用的是子類(lèi)中重寫(xiě)的虛方法
   

因此，ReSharper會(huì)警告我們，這么做存在隱患。

我們能完全避免這么做嗎？很遺憾，答案是不能。比如如果項(xiàng)目中使用了NHibernate，框架本身要求ORM實(shí)體類(lèi)中，所有與數(shù)據(jù)庫(kù)列具有對(duì)應(yīng)關(guān)系的屬性都必須為虛屬性。這是因?yàn)镹Hibernate為了實(shí)現(xiàn)延遲加載，會(huì)為每個(gè)實(shí)體類(lèi)生成proxy，這些proxy需要重寫(xiě)實(shí)體類(lèi)中屬性的getter/setter。而有些時(shí)候，為了業(yè)務(wù)需要，我們不得不在實(shí)體類(lèi)的構(gòu)造函數(shù)中對(duì)這些屬性進(jìn)行某些操作（比如初始化）。

我認(rèn)為這么做是技術(shù)選型所致的必然結(jié)果，是完全可以接受的。但我們要注意，在代碼中保證那些可能會(huì)被繼承的實(shí)體，在子類(lèi)中重寫(xiě)那些虛屬性時(shí)，不要依賴(lài)于子類(lèi)自身的構(gòu)造函數(shù)（這幾乎是可以保證的，因?yàn)榕c數(shù)據(jù)庫(kù)列映射的屬性，只能是最簡(jiǎn)單的getter/setter）。

以上就是C# 構(gòu)造函數(shù)如何調(diào)用虛方法的詳細(xì)內(nèi)容，更多關(guān)于C# 構(gòu)造函數(shù)內(nèi)調(diào)用虛方法的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論