關于C#構造函數(shù)調用虛方法的案例分析

小編給大家分享一下關于C#構造函數(shù)調用虛方法的案例分析，希望大家閱讀完這篇文章后大所收獲，下面讓我們一起去探討方法吧！

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

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

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

  public virtual string Name { get; set; }

  public virtual void Solve()
  {
  }
}

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

這是什么原因呢？我們在構造函數(shù)中調用虛方法，礙著ReSharper什么事兒了？

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

類型的初始化順序

我們先來看這樣一段代碼：

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();
  }
}

猜一猜它的輸出結果是什么？

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

Base constructor
Derived constructor

我們在初始化一個對象時，總是會先執(zhí)行基類的構造函數(shù)，然后再執(zhí)行子類的構造函數(shù)。

虛方法調用

我們再來看一段代碼：

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();
  }
}

再來猜一猜輸出結果吧。

貌似應該是：

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

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

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

這是為什么呢？

原來對于非虛方法調用，編譯器會進行一些額外的“動作”。比如找出所調用對象的實際類型，以訪問正確的方法表（調用b.V()的時候就會找到變量b的實際類型Derived，從而輸出Derived.V）。

解惑

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

我們稍微改造一下虛方法調用的那個例子。

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的構造函數(shù)中調用虛方法V()時，ReSharper會給出virtual member call in constructor的警告。這是因為V可以在Base的任意子類中被改寫（override），而這種改寫，很有可能使得它依賴于自己的構造函數(shù)，如上例所示。而由于之前提到的類型初始化順序，在執(zhí)行Base b = new Derived();這樣的代碼時，Base的構造函數(shù)要早于Derived的構造函數(shù)執(zhí)行，因此在執(zhí)行到foo.Bar()時foo還是個空引用。

明白了嗎？我們來簡單總結一下。Virtual member call in constructor的警告是因為，對于Base b = new Derived();這樣的代碼：

1. 基類構造函數(shù)的執(zhí)行要早于子類構造函數(shù)
2. 基類構造函數(shù)中對于虛方法的調用，實際調用的是子類中重寫的虛方法
    

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

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

我認為這么做是技術選型所致的必然結果，是完全可以接受的。但我們要注意，在代碼中保證那些可能會被繼承的實體，在子類中重寫那些虛屬性時，不要依賴于子類自身的構造函數(shù)

看完了這篇文章，相信你對關于C#構造函數(shù)調用虛方法的案例分析有了一定的了解，想了解更多相關知識，歡迎關注億速云行業(yè)資訊頻道，感謝各位的閱讀！