Герберт Шилдт - C# 4.0 полное руководство - 2011
}
// ...
}
class VarianceDemo { static void Main() {
// Создать ссылку из интерфейса IMyContraVarGenIF<Alpha>
//на объект типа MyClass<Alpha>.
// Это вполне допустимо как при наличии контравариантности, так и без нее. IMyContraVarGenIF<Alpha> AlphaRef = new MyClass<Alpha>();
// Создать ссылку из интерфейса IMyContraVarGenIF<beta>
// на объект типа MyClass<Beta>.
//И это вполне допустимо как при наличии контравариантности,
// так и без нее.
IMyContraVarGenIF<Beta> BetaRef = new MyClass<Beta>();
// Создать ссылку из интерфейса IMyContraVarGenIF<beta>
//на объект типа MyClass<Alpha>.
// *** Это вполне допустимо благодаря контравариантности. *** IMyContraVarGenIF<Beta> BetaRef2 = new MyClass<Alpha>();
// Этот вызов допустим как при наличии контравариантности, так и без нее. BetaRef.Show(new Beta());
// Присвоить переменную AlphaRef переменной BetaRef.
// *** Это вполне допустимо благодаря контравариантности. ***
BetaRef = AlphaRef;
BetaRef.Show(new Beta ());
}
}
Выполнение этой программы дает следующий результат.
Это объект класса Beta.
Это объект класса Beta.
Контравариантный интерфейс может быть расширен аналогично описанному выше расширению ковариантного интерфейса. Для достижения контравариантного характера расширенного интерфейса в его объявлении должен быть указан такой же параметр обобщенного типа, как и у базового интерфейса, но с ключевым словом in, как показано ниже.
public interface IMyContraVarGenIF2<in Т> : IMyContraVarGenIF<T> {
// ...
}
Следует иметь в виду, что указывать ключевое слово in в объявлении базового интерфейса не только не нужно, но и не допустимо. Более того, сам расширенный интерфейс IMyContraVarGenIF2 не обязательно должен быть контравариантным. Иными словами, обобщенный тип Т в интерфейсе IMyContraVarGenIF2 не требуется модифицировать ключевым словом in. Разумеется, все преимущества, которые сулит контравариантность в интерфейсе IMyContraVarGen, при этом будут утрачены в интерфейсе IMyContraVarGenIF2.
Контравариантность оказывается пригодной только для ссылочных типов, а параметр контравариантного типа можно применять только к аргументам методов. Следовательно, ключевое слово in нельзя указывать в параметре типа, используемом в качестве возвращаемого типа.
Вариантные делегаты
Как пояснялось в главе 15, ковариантность и контравариантность поддерживается в необобщенных делегатах в отношении типов, возвращаемых методами, и типов, указываемых при объявлении параметров. Начиная с версии C# 4.0, возможности ковариантности и контравариантности были распространены и на обобщенные делегаты. Подобные возможности действуют таким же образом, как было описано выше в отношении обобщенных интерфейсов.
Ниже приведен пример контравариантного делегата.
// Объявить делегат, контравариантный по отношению к обобщенному типу Т. delegate bool SomeOpcin Т>(Т obj);
Этому делегату можно присвоить метод с параметром обобщенного типа Т или же класс, производный от типа Т.
А вот пример ковариантного делегата.
// Объявить делегат, ковариантный по отношению к обобщенному типу Т. delegate Т AnotherOp<out Т, V>(V obj);
Этому делегату можно присвоить метод, возвращающий обобщенный тип Т, или же класс, производный от типа Т. В данном случае V оказывается просто параметром инвариантного типа.
В следующем примере программы демонстрируется применение обоих разновидностей вариантных делегатов на практике.
// Продемонстрировать конвариантность и контравариантность // в обобщенных делегатах.
using System;
// Объявить делегат, контравариантный по отношению к обобщенному типу Т. delegate bool SomeOpcin Т>(Т obj);
// Объявить делегат, ковариантный по отношению к обобщенному типу Т. delegate Т AnotherOpCout Т, V>(V obj);
class Alpha {
public int Val { get; set; }
public Alpha(int v) { Val = v; }
}
class Beta : Alpha {
public Beta (int v) : base (v) {• }
}
class GenDelegateVarianceDemo {
// Возвратить логическое значение true, если значение // переменной obj.Val окажется четным, static bool IsEven(Alpha obj) {
if((obj.Val % 2) == 0) return true; return false;
}
static Beta Changelt(Alpha obj) { return new Beta(obj.Val +2);
}
static void Main() {
Alpha objA = new Alpha(4);
Beta objB = new Beta(9);
// Продемонстрировать сначала контравариантность.
// Объявить делегат SomeOp<Alpha> и задать для него метод IsEven. SomeOp<Alpha> checklt = IsEven;
// Объявить делегат SomeOp<Beta>.
SomeOp<Beta> checklt2;
//А теперь- присвоить делегат SomeOp<Alpha> делегату SomeOp<Beta>.
// *** Это допустимо только благодаря контравариантности. *** checklt2 = checklt;
// Вызвать метод через делегат.
Console.WriteLine(checklt2(objB));
// Далее, продемонстрировать контравариантность.
// Объявить сначала два делегата типа AnotherOp.
// Здесь возвращаемым типом является класс Beta,
//а параметром типа — класс Alpha.
// Обратите внимание на то, что для делегата modifylt // задается метод Changelt.
AnotherOp<Beta, Alpha> modifylt = Changelt;
// Здесь возвращаемым типом является класс Alpha,
// а параметром типа — тот же класс Alpha.
AnotherOp<Alpha, Alpha> modifyIt2;
// А теперь присвоить делегат modifylt делегату modifyIt2.
// *** Это допустимо только благодаря ковариантности. *** modifyIt2 = modifylt;
// Вызвать метод и вывести результаты на экран. objA = modifyIt2(objA);
Console.WriteLine(objA.Val);
}
}
Выполнение этой программы приводит к следующему результату.
False
6
Каждая операция достаточно подробно поясняется в комментариях к данной программе. Следует особо подчеркнуть, для успешной компиляции программы в объявлении обоих типов делегатов SomeOp and AnotherOp должны быть непременно указаны ключевые слова in и out соответственно. Без этих модификаторов компиляция программы будет выполнена с ошибками из-за отсутствия неявных преобразований типов в означенных строках кода.
Создание экземпляров объектов обобщенных типов
Когда приходится иметь дело с обобщениями, то нередко возникает вопрос: не приведет ли применение обобщенного класса к неоправданному раздуванию кода? Ответ на этот вопрос прост: не приведет. Дело в том, что в C# обобщения реализованы весьма эффективным образом: новые объекты конструируемого типа создаются лишь по мере надобности. Этот процесс описывается ниже.
Когда обобщенный класс компилируется в псевдокод MSIL, он сохраняет все свои параметры типа в их обобщенной форме. А когда конкретный экземпляр класса потребуется во время выполнения программы, то JIT-компилятор сконструирует конкретный вариант этого класса в исполняемом коде, в котором параметры типа заменяются аргументами типа. В каждом экземпляре с теми же самыми аргументами типа будет использоваться один и тот же вариант данного класса в исполняемом коде.
Так, если имеется некоторый обобщенный класс Gen<T>, то во всех объектах типа Gen<T> будет использоваться один и тот же исполняемый код данного класса. Следовательно, раздувание кода исключается благодаря тому, что в программе создаются только те варианты класса, которые действительно требуются. Когда же возникает потребность сконструировать объект другого типа, то компилируется новый вариант класса в исполняемом коде.
Как правило, новый исполняемый вариант обобщенного класса создается для каждого объекта конструируемого типа, в котором аргумент имеет тип значения, например int или double. Следовательно, в каждом объекте типа Gen<int> будет использоваться один исполняемый вариант класса Gen, а в каждом объекте типа Gen<double> — другой вариант класса Gen, причем каждый вариант приспосабливается к конкретному типу значения. Но во всех случаях, когда аргумент оказывается ссылочного типа, используется только один вариант обобщенного класса, поскольку все ссылки имеют одинаковую длину (в байтах). Такая оптимизация также исключает раздувание кода.
Некоторые ограничения, присущие обобщениям
