Почему это работает? Перегрузка метода + переопределение метода + полиморфизм

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

Это может привести к тонким и трудно обнаруживаемым проблемам, как показано здесь.

Например, попробуйте этот код (сначала прочитайте его, затем скомпилируйте и выполните), посмотрите, делает ли он то, что вы от него ожидаете.

using System;

namespace ConsoleApplication9
{
    public class Base
    {
        public virtual void Test(String s)
        {
            Console.Out.WriteLine("Base.Test(String=" + s + ")");
        }
    }

    public class Descendant : Base
    {
        public override void Test(String s)
        {
            Console.Out.WriteLine("Descendant.Test(String=" + s + ")");
        }

        public void Test(Object s)
        {
            Console.Out.WriteLine("Descendant.Test(Object=" + s + ")");
        }
    }

    class Program
    {
        static void Main(string[] args)
        {
            Descendant d = new Descendant();
            d.Test("Test");
            Console.In.ReadLine();
        }
    }
}

Обратите внимание, что если вы объявите тип переменной типа Base вместо Descendant, вызов перейдет к другому методу, попробуйте изменить эту строку:

Descendant d = new Descendant();

к этому и повторно запустите:

Base d = new Descendant();

Итак, как же тогда вам удалось позвонить Descendant.Test(String)?

Моя первая попытка выглядит так:

public void Test(Object s)
{
    Console.Out.WriteLine("Descendant.Test(Object=" + s + ")");
    Test((String)s);
}

Это не помогло мне, и вместо этого я просто снова и снова вызывал Test(Object) для возможного переполнения стека.

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

public void Test(Object s)
{
    Console.Out.WriteLine("Descendant.Test(Object=" + s + ")");
    Base b = this;
    b.Test((String)s);
}

Это распечатает:

Descendant.Test(Object=Test)
Descendant.Test(String=Test)

вы также можете сделать это снаружи:

Descendant d = new Descendant();
d.Test("Test");
Base b = d;
b.Test("Test");
Console.In.ReadLine();

распечатает то же самое.

Но сначала вам нужно знать о проблеме, а это совсем другое.

См. раздел Спецификации языка C# в разделе Поиск членов и разрешение перегрузки. Метод переопределения производного класса не является кандидатом из-за правил поиска членов, а метод базового класса не является наилучшим соответствием на основе правил разрешения перегрузки.

Раздел 7.3

Во-первых, конструируется набор всех доступных (раздел 3.5) членов с именем N, объявленных в T, и базовых типов (раздел 7.3.1) T. Объявления, содержащие модификатор переопределения, исключаются из набора. Если члены с именем N не существуют и не доступны, то поиск не дает совпадений, и следующие шаги не оцениваются.

Раздел 7.4.2:

Каждый из этих контекстов определяет набор членов функции-кандидата и список аргументов по-своему, как подробно описано в разделах, перечисленных выше. Например, набор кандидатов для вызова метода не включает методы, помеченные как переопределение (раздел 7.3), а методы базового класса не являются кандидатами, если применим любой метод производного класса (раздел 7.5). .5.1). (выделено мной)

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

Это кажется нелогичным. Конечно, если в базовом классе объявлено точное совпадение, то это лучше, чем неточное совпадение, объявленное в производном классе, да?

Нет. Есть две причины всегда выбирать более производный метод, а не менее производный.

Во-первых, автор производного класса имеет гораздо больше информации, чем автор базового класса. Автор производного класса знает все как о базовом классе , так и о производном классе, который, в конце концов, является классом, который на самом деле использует вызывающая сторона. Когда есть выбор между вызовом метода, написанного кем-то, кто знает все, и кем-то, кто знает только кое-что о типе, который использует вызывающий, очевидно, что имеет смысл отдать приоритет вызову метода, написанного разработчиком производного класса.

Во-вторых, такой выбор приводит к одной из форм Сбоя Хрупкого Базового Класса. Мы хотим защитить вас от этого сбоя, и поэтому написали правила разрешения перегрузки, чтобы по возможности избежать этого.

Подробное объяснение того, как это правило защищает вас от отказа хрупкого базового класса, см. в моей статье на эту тему:

http://blogs.msdn.com/ericlippert/archive/2007/09/04/future-breaking-changes-part-three.aspx

А статьи о других способах взаимодействия языков с ситуациями хрупкого базового класса см.:

http://blogs.msdn.com/b/ericlippert/archive/tags/brittle+base+classes/

Потому что так определяется язык. Для виртуальных элементов реализация, которая вызывается во время выполнения, когда метод существует как в базовом, так и в производном классе, основана на конкретном типе< /strong> объекта, для которого вызывается метод, а не объявленный тип переменной, которая содержит ссылку на объект. Ваш первый MyMethod находится в абстрактном классе. Таким образом, его нельзя никогда вызывать из объекта типа MyClass, потому что такой объект никогда не может существовать. Все, что вы можете создать, это производный класс MySubClass. Конкретным типом является MySubClass, поэтому вызывается эта реализация, независимо от того, что вызывающий ее код находится в базовом классе.