Wirtualne wywołanie członka w konstruktorze

Aby odpowiedzieć na twoje pytanie, rozważ to pytanie: co zostanie wydrukowany poniższy kod, gdy obiekt Child zostanie utworzony?

class Parent
{
    public Parent()
    {
        DoSomething();
    }

    protected virtual void DoSomething() 
    {
    }
}

class Child : Parent
{
    private string foo;

    public Child() 
    { 
        foo = "HELLO"; 
    }

    protected override void DoSomething()
    {
        Console.WriteLine(foo.ToLower()); //NullReferenceException!?!
    }
}

Odpowiedź jest taka, że w rzeczywistości a NullReferenceException zostanie wyrzucone, ponieważ foo jest null. konstruktor bazowy obiektu jest wywoływany przed własnym konstruktorem . Poprzez wywołanie virtual w konstruktorze obiektu wprowadzasz możliwość, że dziedziczące obiekty wykonają kod zanim zostaną w pełni zainicjalizowane.

Zasady C# bardzo różnią się od zasad Javy i C++.

Gdy znajdujesz się w konstruktorze jakiegoś obiektu w C#, Obiekt ten istnieje w pełni zainicjalizowanej (tylko nie "skonstruowanej") formie, jako jego w pełni Pochodny Typ.

namespace Demo
{
    class A 
    {
      public A()
      {
        System.Console.WriteLine("This is a {0},", this.GetType());
      }
    }

    class B : A
    {      
    }

    // . . .

    B b = new B(); // Output: "This is a Demo.B"
}

Oznacza to, że jeśli wywołasz wirtualną funkcję z konstruktora a, zostanie ona rozwiązana do dowolnego nadpisania w B, jeśli taka zostanie dostarczona.

Nawet jeśli celowo skonfigurujesz A i B w ten sposób, w pełni rozumiejąc zachowanie systemu, możesz być później w szoku. Powiedzmy, że nazwałeś funkcje wirtualne w konstruktorze B, "wiedząc", że będą one obsługiwane przez B lub A odpowiednio. Potem czas mija, a ktoś inny decyduje, że musi zdefiniować C i nadpisać niektóre z wirtualnych funkcji. Nagle konstruktor B kończy wywołanie kodu w C, co może prowadzić do dość zaskakującego zachowania.

Prawdopodobnie dobrym pomysłem jest unikanie funkcji wirtualnych w konstruktorach, ponieważ reguły są więc różni się między C#, C++ i Java. Twoi programiści mogą nie wiedzieć, czego się spodziewać!

Powody ostrzeżenia są już opisane, ale jak naprawić Ostrzeżenie? Musisz zapieczętować klasę lub członka Wirtualnego.

  class B
  {
    protected virtual void Foo() { }
  }

  class A : B
  {
    public A()
    {
      Foo(); // warning here
    }
  }

Można uszczelnić klasę A:

  sealed class A : B
  {
    public A()
    {
      Foo(); // no warning
    }
  }

Lub możesz uszczelnić metodę Foo:

  class A : B
  {
    public A()
    {
      Foo(); // no warning
    }

    protected sealed override void Foo()
    {
      base.Foo();
    }
  }

W C# konstruktor klasy bazowej uruchamia Przed konstruktorem klasy pochodnej, więc wszelkie pola instancji, które Klasa pochodna może użyć w potencjalnie nadpisanym elemencie wirtualnym, nie są jeszcze inicjalizowane.

Należy pamiętać, że to jest tylko Ostrzeżenie , aby zwrócić uwagę i upewnić się, że wszystko jest w porządku. Istnieją rzeczywiste przypadki użycia tego scenariusza, wystarczy udokumentować zachowanie Wirtualnego członka, że nie może on używać żadnych pól instancji zadeklarowanych w Klasa pochodna poniżej, gdzie konstruktor ją wywołujący.

Są dobrze napisane odpowiedzi powyżej, dlaczego nie chcesz tego zrobić. Oto przeciw-przykład, w którym być może chciałbyś to zrobić (przetłumaczone na C# z praktycznego projektowania obiektowego w Ruby autorstwa Sandi Metz, str. 126).

Zauważ, że GetDependency() nie dotyka żadnych zmiennych instancji. Byłoby statyczne, gdyby statyczne metody mogły być wirtualne.

(szczerze mówiąc, są prawdopodobnie mądrzejsze sposoby na zrobienie tego za pomocą kontenerów iniekcji zależności lub inicjalizatory obiektów...)

public class MyClass
{
    private IDependency _myDependency;

    public MyClass(IDependency someValue = null)
    {
        _myDependency = someValue ?? GetDependency();
    }

    // If this were static, it could not be overridden
    // as static methods cannot be virtual in C#.
    protected virtual IDependency GetDependency() 
    {
        return new SomeDependency();
    }
}

public class MySubClass : MyClass
{
    protected override IDependency GetDependency()
    {
        return new SomeOtherDependency();
    }
}

public interface IDependency  { }
public class SomeDependency : IDependency { }
public class SomeOtherDependency : IDependency { }

Tak, ogólnie źle jest wywoływać metodę wirtualną w konstruktorze.

W tym momencie obiekt może nie być jeszcze w pełni skonstruowany, a niezmienniki oczekiwane przez metody mogą nie być jeszcze utrzymane.

Twój konstruktor może (później, w rozszerzeniu Twojego oprogramowania) zostać wywołany z konstruktora podklasy, która nadpisuje metodę wirtualną. Teraz nie zostanie wywołana implementacja funkcji podklasy, ale Implementacja klasy bazowej. Więc nie ma sensu wywoływać tutaj funkcji wirtualnej.

Jednakże, jeśli twój projekt spełnia zasadę substytucji Liskowa, nic się nie stanie. Prawdopodobnie dlatego jest tolerowane-Ostrzeżenie, a nie błąd.

Ważnym aspektem tego pytania, którego inne odpowiedzi jeszcze nie rozwiązały, jest to, że jest bezpieczne dla klasy bazowej wywoływanie wirtualnych członków z jej konstruktora , jeśli tego oczekują klasy pochodne. W takich przypadkach projektant klasy pochodnej jest odpowiedzialny za zapewnienie, że wszelkie metody uruchamiane przed ukończeniem budowy będą zachowywać się tak rozsądnie, jak to tylko możliwe w danych okolicznościach. Na przykład w C++/CLI konstruktory są owinięte w kodzie, który wywoła Dispose Na częściowo zbudowanym obiekcie, jeśli Budowa się nie powiedzie. Wywołanie Dispose w takich przypadkach jest często konieczne, aby zapobiec wyciekom zasobów, ale Dispose metody muszą być przygotowane na możliwość, że obiekt, na którym są uruchamiane, może nie być w pełni skonstruowany.

Ponieważ dopóki konstruktor nie zakończy wykonywania, obiekt nie jest w pełni instancjowany. Członkowie, do których odwołuje się funkcja wirtualna, mogą nie zostać zainicjowani. W C++, gdy znajdujesz się w konstruktorze, this odnosi się tylko do statycznego typu konstruktora, w którym się znajdujesz, a nie do rzeczywistego dynamicznego typu tworzonego obiektu. Oznacza to, że wirtualne wywołanie funkcji może nawet nie pójść tam, gdzie tego oczekujesz.

Ostrzeżenie jest przypomnieniem, że członkowie wirtualni mogą zostać nadpisani na klasie pochodnej. W takim przypadku to, co Klasa rodzica zrobiła wirtualnemu członkowi, zostanie cofnięte lub zmienione przez nadpisanie klasy potomnej. Spójrz na mały przykład blow dla jasności

Klasa rodzica poniżej próbuje ustawić wartość na wirtualny element w konstruktorze. A to spowoduje ponowne ostrzejsze Ostrzeżenie, zobaczmy na kodzie:

public class Parent
{
    public virtual object Obj{get;set;}
    public Parent()
    {
        // Re-sharper warning: this is open to change from 
        // inheriting class overriding virtual member
        this.Obj = new Object();
    }
}

Klasa potomna nadpisuje właściwość rodzica. Jeśli to właściwość nie była zaznaczona wirtualnie kompilator ostrzegałby, że właściwość ukrywa właściwość w klasie nadrzędnej i sugerowałby dodanie słowa kluczowego' new', jeśli jest to zamierzone.

public class Child: Parent
{
    public Child():base()
    {
        this.Obj = "Something";
    }
    public override object Obj{get;set;}
}

Wreszcie wpływ na użycie, wynik poniższego przykładu porzuca wartość początkową ustawioną przez konstruktor klasy nadrzędnej. i to jest to, co Re-sharper próbuje cię ostrzec, wartości ustawione w konstruktorze klasy nadrzędnej są otwarte do nadpisania przez konstruktor klasy podrzędnej, który jest wywoływany tuż po konstruktorze klasy nadrzędnej .

public class Program
{
    public static void Main()
    {
        var child = new Child();
        // anything that is done on parent virtual member is destroyed
        Console.WriteLine(child.Obj);
        // Output: "Something"
    }
} 

Strzeżcie się ślepo podążać za radą Resharpera i zapieczętować klasę! Jeśli jest to model w kodzie EF najpierw usunie wirtualne słowo kluczowe, a to wyłączy leniwe Ładowanie jego relacji.

    public **virtual** User User{ get; set; }

Jednym z ważnych brakujących bitów jest, jaki jest prawidłowy sposób rozwiązania tego problemu?

Jak wyjaśnił Greg , głównym problemem jest to, że konstruktor klasy bazowej wywoła Wirtualnego członka przed zbudowaniem klasy pochodnej.

Poniższy kod, zaczerpnięty z MSDN ' s constructor design guidelines , pokazuje ten problem.

public class BadBaseClass
{
    protected string state;

    public BadBaseClass()
    {
        this.state = "BadBaseClass";
        this.DisplayState();
    }

    public virtual void DisplayState()
    {
    }
}

public class DerivedFromBad : BadBaseClass
{
    public DerivedFromBad()
    {
        this.state = "DerivedFromBad";
    }

    public override void DisplayState()
    {   
        Console.WriteLine(this.state);
    }
}

Kiedy tworzona jest nowa instancja DerivedFromBad, konstruktor klasy bazowej wywołuje DisplayState i pokazuje BadBaseClass ponieważ pole nie zostało jeszcze zaktualizowane przez konstruktor Pochodny.

public class Tester
{
    public static void Main()
    {
        var bad = new DerivedFromBad();
    }
}

Ulepszona implementacja usuwa metodę wirtualną z konstruktora klasy bazowej i używa metody Initialize. Tworzenie nowej instancji DerivedFromBetter wyświetla oczekiwany "DerivedFromBetter"

public class BetterBaseClass
{
    protected string state;

    public BetterBaseClass()
    {
        this.state = "BetterBaseClass";
        this.Initialize();
    }

    public void Initialize()
    {
        this.DisplayState();
    }

    public virtual void DisplayState()
    {
    }
}

public class DerivedFromBetter : BetterBaseClass
{
    public DerivedFromBetter()
    {
        this.state = "DerivedFromBetter";
    }

    public override void DisplayState()
    {
        Console.WriteLine(this.state);
    }
}

Jest różnica między C++ i C# w tym konkretnym przypadku. W C++ Obiekt nie jest inicjowany i dlatego nie jest bezpieczne wywołanie funkcji virutal wewnątrz konstruktora. W C# gdy obiekt klasy jest tworzony, wszystkie jego członkowie są inicjalizowane zerem. Możliwe jest wywołanie funkcji wirtualnej w konstruktorze, ale jeśli będziesz mógł uzyskać dostęp do członków, które nadal są zerowe. Jeśli nie potrzebujesz dostępu do członków, jest całkiem bezpieczne wywołanie funkcji wirtualnej w C#.

Dodam tylko moje przemyślenia. Jeśli zawsze inicjalizujesz pole prywatne, gdy je zdefiniujesz, tego problemu należy unikać. Przynajmniej poniższy kod działa jak urok:

class Parent
{
    public Parent()
    {
        DoSomething();
    }
    protected virtual void DoSomething()
    {
    }
}

class Child : Parent
{
    private string foo = "HELLO";
    public Child() { /*Originally foo initialized here. Removed.*/ }
    protected override void DoSomething()
    {
        Console.WriteLine(foo.ToLower());
    }
}

Kolejną ciekawą rzeczą, którą odkryłem, jest to, że błąd ReSharper może być "spełniony", robiąc coś takiego jak poniżej, co jest dla mnie głupie (jednak, jak wspomniano wcześniej, nadal nie jest dobrym pomysłem, aby wywoływać wirtualne prop/metody w ctor.

public class ConfigManager
{

   public virtual int MyPropOne { get; private set; }
   public virtual string MyPropTwo { get; private set; }

   public ConfigManager()
   {
    Setup();
   }

   private void Setup()
   {
    MyPropOne = 1;
    MyPropTwo = "test";
   }

}

Dodałbym metodę Initialize() do klasy bazowej, a następnie wywołałbym ją z pochodnych konstruktorów. Ta metoda wywoła dowolne wirtualne / abstrakcyjne metody/właściwości po wykonaniu wszystkich konstruktorów:)