Contravariance explained

(Отредактировано в ответ на комментарии)

В этой статье MSDN по теме описываются ковариация и контравариантность в применении к сопоставлению функции с делегатом. Переменная типа делегата:

public delegate bool Compare(Giraffe giraffe, Dolphin dolphin);

может (из-за контравариантности) быть заполнена функцией:

public bool Compare(Mammal mammal1, Mammal mammal2)
{
    return String.Compare(mammal1.Name, mammal2.Name) == 0;
}

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

Ковариативность и Contravariance - это не то, что вы можете наблюдать при работе с классами инстанцирования. Поэтому неправильно говорить об одном из них, когда смотришь на простую инстанцирование класса, как в вашем примере: Animal someAnimal = new Giraffe(); //ковариантная операция

Эти термины не классифицируют операции. Термины Covariance, Contravariance и Invariance описывают связь между определенными аспектами классов и их подклассами.

Covariance

означает, что аспект изменяется аналогично направлению наследования.

Противоречие

означает, что аспект изменяется в направлении, противоположном направлению наследования.

Неопределенность

означает, что аспект не изменяется из класса в его подкласс (подклассы).

Обычно мы рассматриваем следующие аспекты, когда говорим о Ков.., Contrav. и Inv.:

• Методы
  • Типы параметров
  • Типы возврата
  • Другие аспекты, связанные с сигнатурой, такие как брошенные исключения.
• Дженерики

Давайте рассмотрим несколько примеров, чтобы лучше понять термины.

class T
class T2 extends T
 
//Covariance: The return types of the method "method" have the same
//direction of inheritance as the classes A and B.
class A { T method() }
class B extends A { T2 method() }
 
//Contravariance: The parameter types of the method "method" have a
//direction of inheritance opposite to the one of the classes A and B.
class A { method(T2 t) }
class B { method(T t) }

В обоих случаях "метод" переопределяется! Далее, приведенные примеры являются единственными правовыми случаями Cov. и Contrav. в объектно-ориентированных языках..:

• Covariance - Return types and exception throw statements
• Contravariance - Input parameters
• Invariance - Input and Output parameters

Давайте рассмотрим некоторые примеры счетчиков, чтобы лучше понять приведенный выше список:

//Covariance of return types: OK
class Monkey { Monkey clone() }
class Human extends Monkey { Human clone() }
 
Monkey m = new Human();
Monkey m2 = m.clone(); //You get a Human instance, which is ok,
                       //since a Human is-a Monkey.
 
//Contravariance of return types: NOT OK
class Fruit
class Orange extends Fruit
 
class KitchenRobot { Orange make() }
class Mixer extends KitchenRobot { Fruit make() }
 
KitchenRobot kr = new Mixer();
Orange o = kr.make(); //Orange expected, but got a fruit (too general!)
 
//Contravariance of parameter types: OK
class Food
class FastFood extends Food
 
class Person { eat(FastFood food) }
class FatPerson extends Person { eat(Food food) }
 
Person p = new FatPerson();
p.eat(new FastFood()); //No problem: FastFood is-a Food, which FatPerson eats.
 
//Covariance of parameter types: NOT OK
class Person { eat(Food food) }
class FatPerson extends Person { eat(FastFood food) }
 
Person p = new FatPerson();
p.eat(new Food()); //Oops! FastFood expected, but got Food (too general).

Эта тема настолько сложна, что я могу продолжить ее очень долго. Советую вам самостоятельно проверить Cov. и Contrav. из Generics. Далее, вам нужно знать, как работает динамическая привязка, чтобы полностью понять примеры (какие методы получают точное название).

Термины возникли из принципа замещения Лискова, который определяет необходимые критерии для моделирования типа данных как подтипа другого. Возможно, вы также захотите исследовать его.

.