Почему концепции ковариации и контравариантности применимы при реализации методов интерфейса?

Ненарушенная реализация вариативности реализации интерфейса должна быть ковариантной по возвращаемому типу и контравариантной по типам аргументов.

Например:

public interface IFoo
{
    object Flurp(Array array);
}

public class GoodFoo : IFoo
{
    public int Flurp(Array array) { ... }
}

public class NiceFoo : IFoo
{
    public object Flurp(IEnumerable enumerable) { ... }
}

Оба законны по «новым» правилам, верно? Но как насчет этого:

public class QuestionableFoo : IFoo
{
    public double Flurp(Array array) { ... }
    public object Flurp(IEnumerable enumerable) { ... }
}

Трудно сказать, какая неявная реализация здесь лучше. Первый является точным совпадением для типа аргумента, но не для типа возвращаемого значения. Второе — это точное совпадение для типа возвращаемого значения, но не для типа аргумента. Я склоняюсь к первому, потому что тот, кто использует интерфейс IFoo, может поставить ему только Array, но это все равно не совсем понятно.

И это далеко не самое худшее. Что, если мы сделаем это вместо этого:

public class EvilFoo : IFoo
{
    public object Flurp(ICollection collection) { ... }
    public object Flurp(ICloneable cloneable) { ... }
}

Кто из них получит приз? Это вполне допустимая перегрузка, но ICollection и ICloneable не имеют ничего общего друг с другом, а Array реализует их обе. Я не вижу здесь очевидного решения.

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

public interface ISuck
{
    Stream Munge(ArrayList list);
    Stream Munge(Hashtable ht);
    string Munge(NameValueCollection nvc);
    object Munge(IEnumerable enumerable);
}

public class HateHateHate : ISuck
{
    public FileStream Munge(ICollection collection);
    public NetworkStream Munge(IEnumerable enumerable);
    public MemoryStream Munge(Hashtable ht);
    public Stream Munge(ICloneable cloneable);
    public object Munge(object o);
    public Stream Munge(IDictionary dic);
}

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

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

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

Позвольте мне перефразировать вопрос:

Такие языки, как C++, позволяют переопределяющему методу иметь более конкретный тип возвращаемого значения, чем переопределенный метод. Например, если у нас есть типы

abstract class Enclosure {}
class Aquarium : Enclosure {}
abstract class Animal 
{
    public virtual Enclosure GetEnclosure();
}

тогда это недопустимо в С#, но эквивалентный код будет допустим в С++:

class Fish : Animal
{
    public override Aquarium GetEnclosure() { ... 

Как называется эта особенность C++?

Эта функция называется «ковариация возвращаемого типа». (Как указывает другой ответ, также можно было бы поддерживать «контравариантность формальных параметров», хотя С++ этого не делает.)

Почему это не поддерживается в С#?

Как я уже неоднократно указывал, нам не нужно указывать причину, по которой функция не поддерживается; состояние по умолчанию всех функций "не поддерживается". Только когда на реализацию тратится огромное количество времени и усилий, функция становится поддерживаемой. Скорее, функции, которые внедряются, должны иметь для этого причины, и чертовски веские причины, учитывая, сколько стоит их создание.

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

1. CLR не поддерживает его. Чтобы это работало, нам в основном нужно реализовать точно соответствующий метод, а затем создать вспомогательный метод, который его вызывает. Это выполнимо, но это становится грязным.

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

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

Вы должны реализовать методы интерфейса точно так же, как они есть в интерфейсе. Метод Clone ICloneable возвращает объект, поэтому ваш SomeClass также должен возвращать объект. Однако вы можете без проблем вернуть экземпляр SomeClass в методе SomeClass Clone, но определение метода должно соответствовать интерфейсу:

public class SomeClass: IClonable
 {
     // Some Code

     //Implementing interface method
     Public object Clone()
      {
        SomeClass ret = new SomeClass();
        // copy date from this instance to ret
        return ret;
      }
 }

С точки зрения объяснения причин, лежащих в основе решений C#, Эрик Липперт из Microsoft много написал, объясняя Contra/CoVariance в C#... вот список тегов из его блога: http://blogs.msdn.com/ericlippert/archive/tags/Covariance+and+Contravariance/default.aspx

[Изменить] В зависимости от вашего вопроса, это может быть правильным сообщением. -part-five-interface-variance.aspx" rel="nofollow noreferrer">http://blogs.msdn.com/ericlippert/archive/2007/10/26/covariance-and-contravariance-in-c-part- пять-interface-variance.aspx

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

Об этом говорится здесь:

http://bytes.com/topic/c-sharp/answers/469671-generic-icloneable

По сути, общий интерфейс, который позволит: public class MyClass : IClonable<MyClass>

также позволит: public class MyClass : IClonable<MyOtherClass>

что на самом деле не дает никакой пользы и может все запутать.

Согласно спецификации C#, вы должны использовать метод с идентичной сигнатурой при переопределении или реализации метода интерфейса. Имейте в виду, что Microsoft не владеет C#. Их компилятор C# — это просто его реализация. Так почему же спецификация поступит таким образом? Я могу только догадываться, но я подозреваю, что это было сделано для простоты реализации.