Вызов виртуального члена в конструкторе

Потому что до тех пор, пока конструктор не завершит выполнение, объект не будет полностью создан. Любые члены, на которые ссылается виртуальная функция, не могут быть инициализированы. В C++, когда вы находитесь в конструкторе, this относится только к статическому типу конструктора, в котором вы находитесь, а не к фактическому динамическому типу создаваемого объекта. Это означает, что вызов виртуальной функции может даже пойти не туда, где вы ожидаете.

Да, вообще плохо вызывать виртуальный метод в конструкторе.

На этом этапе объект может быть еще не полностью построен, и инварианты, ожидаемые методами, могут еще не выполняться.

Чтобы ответить на ваш вопрос, рассмотрите следующий вопрос: что будет напечатан приведенный ниже код при создании экземпляра объекта Child?

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!?!
    }
}

Ответ заключается в том, что на самом деле будет выброшен NullReferenceException, потому что foo имеет значение NULL. Базовый конструктор объекта вызывается перед собственным конструктором. Имея вызов virtual в конструкторе объекта, вы создаете возможность того, что наследующие объекты выполнят код до того, как они будут полностью инициализированы.

В этом конкретном случае есть разница между C++ и C#. В C++ объект не инициализируется, поэтому вызывать виртуальную функцию внутри конструктора небезопасно. В C# при создании объекта класса все его члены инициализируются нулем. Можно вызвать виртуальную функцию в конструкторе, но если вы можете получить доступ к членам, которые все еще равны нулю. Если вам не нужен доступ к членам, вполне безопасно вызывать виртуальную функцию на C#.

В C# конструктор базового класса запускает перед конструктора производного класса, поэтому любые поля экземпляра, которые производный класс может использовать в возможно замещенном виртуальном члене, еще не инициализированы.

Обратите внимание, что это просто предупреждение, чтобы заставить вас обратить внимание и убедиться, что все в порядке. Существуют фактические варианты использования для этого сценария, вам просто нужно задокументировать поведение виртуального члена, чтобы он не мог использовать какие-либо поля экземпляра, объявленные в производном классе ниже, где его вызывает конструктор.

Когда создается объект, написанный на C#, происходит то, что инициализаторы запускаются по порядку от самого производного класса к базовому классу, а затем конструкторы запускаются по порядку от базового класса к самому производному классу (см. блог Эрика Липперта, чтобы узнать, почему это).

Кроме того, в .NET объекты не изменяют тип по мере их создания, а начинаются как наиболее производный тип с таблицей методов для наиболее производного типа. Это означает, что вызовы виртуальных методов всегда выполняются для наиболее производного типа.

Когда вы объединяете эти два факта, вы остаетесь с проблемой, заключающейся в том, что если вы вызовете виртуальный метод в конструкторе, а это не самый производный тип в его иерархии наследования, он будет вызываться для класса, конструктор которого не был run, и поэтому может быть не в подходящем состоянии для вызова этого метода.

Эта проблема, конечно, смягчается, если вы помечаете свой класс как запечатанный, чтобы гарантировать, что это самый производный тип в иерархии наследования - в этом случае совершенно безопасно вызывать виртуальный метод.

Ваш конструктор может (позже, в расширении вашего программного обеспечения) вызываться из конструктора подкласса, который переопределяет виртуальный метод. Теперь будет вызываться не реализация функции подкласса, а реализация базового класса. Так что здесь нет смысла вызывать виртуальную функцию.

Однако, если ваш дизайн удовлетворяет принципу замещения Лискова, вреда не будет. Наверное, поэтому терпят - предупреждение, а не ошибка.

Правила C# сильно отличаются от правил Java и C++.

Когда вы находитесь в конструкторе некоторого объекта в C#, этот объект существует в полностью инициализированной (просто не «сконструированной») форме, как его полностью производный тип.

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"
}

Это означает, что если вы вызываете виртуальную функцию из конструктора A, она разрешит любое переопределение в B, если оно предусмотрено.

Даже если вы намеренно настроите A и B вот так, полностью понимая поведение системы, позже вы можете испытать шок. Допустим, вы вызвали виртуальные функции в конструкторе B, «зная», что они будут обрабатываться B или A в зависимости от ситуации. Затем проходит время, и кто-то другой решает, что ему нужно определить C и переопределить некоторые виртуальные функции там. Внезапно конструктор B вызывает код в C, что может привести к довольно неожиданному поведению.

Вероятно, в любом случае лучше избегать виртуальных функций в конструкторах, поскольку правила находятся сильно различаются в C#, C++ и Java. Ваши программисты могут не знать, чего ожидать!

Причины предупреждения уже описаны, но как исправить предупреждение? Вы должны запечатать либо класс, либо виртуальный член.

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

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

Вы можете запечатать класс A:

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

Или вы можете запечатать метод Foo:

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

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

Одним из важных аспектов этого вопроса, на который еще не были рассмотрены другие ответы, является то, что для базового класса безопасно вызывать виртуальные члены из своего конструктора если это то, что производные классы ожидают от него. В таких случаях разработчик производного класса несет ответственность за обеспечение того, чтобы любые методы, запускаемые до завершения построения, вели себя настолько разумно, насколько это возможно в данных обстоятельствах. Например, в C++ / CLI конструкторы обернуты в код, который вызовет Dispose для частично построенного объекта, если построение завершится неудачно. Вызов Dispose в таких случаях часто необходим для предотвращения утечки ресурсов, но методы Dispose должны быть готовы к тому, что объект, на котором они выполняются, может быть не полностью сконструирован.

Выше есть хорошо написанные ответы о том, почему вы не стал бы хотите это сделать. Вот контрпример, в котором, возможно, вы захотите это сделать с помощью бы (переведено на C# из Практический объектно-ориентированный дизайн в Ruby Сэнди Мец, стр. 126).

Обратите внимание, что GetDependency() не касается переменных экземпляра. Было бы статично, если бы статические методы могли быть виртуальными.

(Честно говоря, есть, вероятно, более разумные способы сделать это с помощью контейнеров для внедрения зависимостей или инициализаторов объектов ...)

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 { }

Еще одна интересная вещь, которую я обнаружил, заключается в том, что ошибку ReSharper можно «удовлетворить», выполнив что-то вроде ниже, что для меня глупо. Однако, как упоминалось многими ранее, вызывать виртуальные свойства / методы в конструкторе по-прежнему не рекомендуется.

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";
   }
}

Один важный недостающий бит: как правильно решить эту проблему?

Как и Грег объяснил, основная проблема здесь в том, что конструктор базового класса вызовет виртуальный член до того, как будет создан производный класс.

Следующий код, взятый из Рекомендации по проектированию конструкторов MSDN, демонстрирует эту проблему.

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

Когда создается новый экземпляр DerivedFromBad, конструктор базового класса вызывает DisplayState и показывает BadBaseClass, поскольку поле еще не было обновлено производным конструктором.

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

Улучшенная реализация удаляет виртуальный метод из конструктора базового класса и использует метод Initialize. При создании нового экземпляра DerivedFromBetter отображается ожидаемый "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);
    }
}

Просто чтобы добавить свои мысли. Если вы всегда инициализируете частное поле при его определении, этой проблемы следует избегать. По крайней мере, приведенный ниже код работает как шарм:

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

Предупреждение является напоминанием о том, что виртуальные члены могут быть переопределены в производном классе. В этом случае все, что родительский класс сделал с виртуальным членом, будет отменено или изменено путем переопределения дочернего класса. Взгляните на небольшой пример удара для ясности.

Приведенный ниже родительский класс пытается установить значение виртуального члена в своем конструкторе. И это вызовет предупреждение Re-Sharper, давайте посмотрим на код:

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

Дочерний класс здесь переопределяет родительское свойство. Если это свойство не было помечено как виртуальное, компилятор предупредит, что свойство скрывает свойство родительского класса, и предложит добавить ключевое слово new, если это сделано намеренно.

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

Наконец, влияние на использование, выходные данные приведенного ниже примера отказываются от начального значения, установленного конструктором родительского класса. И это то, о чем Re-Sharper пытается вас предупредить, значения, установленные в конструкторе родительского класса, открыты для перезаписи конструктором дочернего класса, который вызывается сразу после конструктора родительского класса.

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"
    }
} 

Остерегайтесь слепого следования совету Решарпера и запечатывания класса! Если это модель в EF Code First, она удалит ключевое слово virtual, что отключит ленивую загрузку ее отношений.

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

Я бы просто добавил метод Initialize () к базовому классу, а затем вызвал бы его из производных конструкторов. Этот метод будет вызывать любые виртуальные / абстрактные методы / свойства ПОСЛЕ выполнения всех конструкторов :)

Я думаю, что игнорирование предупреждения может быть законным, если вы хотите дать дочернему классу возможность устанавливать или переопределять свойство, которое родительский конструктор будет использовать сразу:

internal class Parent
{
    public Parent()
    {
        Console.WriteLine("Parent ctor");
        Console.WriteLine(Something);
    }

    protected virtual string Something { get; } = "Parent";
}

internal class Child : Parent
{
    public Child()
    {
        Console.WriteLine("Child ctor");
        Console.WriteLine(Something);
    }

    protected override string Something { get; } = "Child";
}

Риск здесь будет заключаться в том, что дочерний класс установит свойство из своего конструктора, и в этом случае изменение значения произойдет после вызова конструктора базового класса.

Мой вариант использования заключается в том, что я хочу, чтобы дочерний класс предоставлял определенное значение или служебный класс, такой как преобразователь, и я не хочу вызывать метод инициализации на базе.

Результатом вышеизложенного при создании экземпляра дочернего класса является:

Parent ctor
Child
Child ctor
Child