Герберт Шилдт - C# 4.0 полное руководство - 2011
public void Set (T о) { obi = о;
}
public void Set(V o) { ob2 = o;
}
Такой подход кажется вполне обоснованным, поскольку типы Т и V ничем внешне не отличаются. Но подобная перегрузка таит в себе потенциальную неоднозначность.
При таком объявлении класса Gen не соблюдается никаких требований к различению типов Т и V. Например, нет ничего принципиально неправильного в том, что объект класса Gen будет сконструирован так, как показано ниже.
Gencint, int> notOK = new Gencint, int>();
В данном случае оба типа, Т и V, заменяются типом int. В итоге оба варианта метода Set () оказываются совершенно одинаковыми, что, разумеется, приводит к ошибке. Следовательно, при последующей попытке вызвать метод Set () для объекта notOK в методе Main () появится сообщение об ошибке вследствие неоднозначности во время компиляции.
Как правило, методы с параметрами типа перегружаются при условии, что объект конструируемого типа не приводит к конфликту. Следует, однако, иметь в виду, что ограничения на типы не учитываются при разрешении конфликтов, возникающих при перегрузке методов. Поэтому ограничения на типы нельзя использовать для исключения неоднозначности. Конструкторы, операторы и индексаторы с параметрами типа могут быть перегружены аналогично конструкторам по тем же самым правилам.
Ковариантность и контравариантность в параметрах обобщенного типа
В главе 15 ковариантность и контравариантность были рассмотрены в связи с необобщенными делегатами. Эта форма ковариантности и контравариантности по-прежнему поддерживается в С#, поскольку она очень полезна. Но в версии C# 4.0 возможности ковариантности и контравариантности были расширены до параметров обобщенного типа, применяемых в обобщенных интерфейсах и делегатах. Ковариантность и контравариантность применяется, главным образом, для рационального разрешения особых ситуаций, возникающих в связи с применением обобщенных интерфейсов и делегатов, определенных в среде .NET Framework. И поэтому некоторые интерфейсы и делегаты, определенные в библиотеке, были обновлены, чтобы использовать ковариантность и контравариантность параметров типа. Разумеется, преимуществами ковариантности и контравариантности можно также воспользоваться в интерфейсах и делегатах, создаваемых собственными силами. В этом разделе механизмы ковариантности и контравариантности параметров типа поясняются на конкретных примерах.
Применение ковариантности в обобщенном интерфейсе
Применительно к обобщенному интерфейсу ковариантность служит средством, разрешающим методу возвращать тип, производный от класса, указанного в параметре типа. В прошлом возвращаемый тип должен был в точности соответствовать параметру типа в силу строгой проверки обобщений на соответствие типов. Ковариантность смягчает это строгое правило таким образом, чтобы обеспечить типовую безопасность. Параметр ковариантного типа объявляется с помощью ключевого слова out, которое предваряет имя этого параметра.
Для того чтобы стали понятнее последствия применения ковариантности, обратимся к конкретному примеру. Ниже приведен очень простой интерфейс IMyCoVarGenlF, в котором применяется ковариантность.
//В этом обобщенном интерфейсе поддерживается ковариантность, public interface IMyCoVarGenlFCout Т> {
Т GetObject();
}
Обратите особое внимание на то, как объявляется параметр обобщенного типа Т. Его имени предшествует ключевое слово out. В данном контексте ключевое слово out обозначает, что обобщенный тип Т является ковариантным. А раз он ковариантный, то метод GetOb j ect () может возвращать ссылку на обобщенный тип Т или же ссылку на любой класс, производный от типа Т.
Несмотря на свою ковариантность по отношению к обобщенному типу Т, интерфейс IMyCoVarGenlF реализуется аналогично любому другому обобщенному интерфейсу. Ниже приведен пример реализации этого интерфейса в классе MyClass.
// Реализовать интерфейс IMyCoVarGenlF. class MyClass<T> : IMyCoVarGenIF<T> {
T obj;
public MyClass(T v) { obj = v; } public T GetObject() { return obj; }
}
Обратите внимание на то, что ключевое слово out не указывается еще раз в выражении, объявляющем реализацию данного интерфейса в классе MyClass. Это не только не нужно, но и вредно, поскольку всякая попытка еще раз указать ключевое слово out будет расцениваться компилятором как ошибка.
А теперь рассмотрим следующую простую реализацию иерархии классов.
// Создать простую иерархию классов, class Alpha { string name;
public Alpha(string n) { name = n; }
public string GetNameO { return name; }
// ...
}
class Beta : Alpha {
public Beta(string n) : base (n) { }
// ...
}
Как видите, класс Beta является производным от класса Alpha.
С учетом всего изложенного выше, следующая последовательность операций будет считаться вполне допустимой.
// Создать ссылку из интерфейса IMyCoVarGenlF на объект типа MyClass<Alpha>.
// Это вполне допустимо как при наличии ковариантности, так и без нее. IMyCoVarGenIF<Alpha> AlphaRef =
new MyClass<Alpha>(new Alpha("Alpha #1"));
Console.WriteLine("Имя объекта, на который ссылается переменная AlphaRef: " + AlphaRef.GetObj ect() .GetName());
//А теперь создать объект MyClass<Beta> и присвоить его переменной AlphaRef.
// *** Эта строка кода вполне допустима благодаря ковариантности. ***
AlphaRef = new MyClass<Beta>(new Beta("Beta #1"));
Console.WriteLine("Имя объекта, на который теперь ссылается " +
"переменная AlphaRef: " + AlphaRef.GetObject().GetName());
Прежде всего, переменной-AlphaRef типа IMyCoVarGenIF<Alpha> в этом фрагменте кода присваивается ссылка на объект типа MyClass<Alpha>. Это вполне допустимая операция, поскольку в классе MyClass реализуется интерфейс IMyCoVarGenlF, причем и в том, и в другом в качестве аргумента типа указывается Alpha. Далее имя объекта выводится на экран при вызове метода GetName () для объекта, возвращаемого методом GetOb j ect (). И эта операция вполне допустима, поскольку Alpha — это и тип, возвращаемый методом GetName (), и обобщенный тип Т. После этого переменной AlphaRef присваивается ссылка на экземпляр объекта типа MyClass<Beta>, что также допустимо, потому что класс Beta является производным от класса Alpha, а обобщенный тип Т — ковариантным в интерфейсе IMyCoVarGenlF. Если бы любое из этих условий не выполнялось, данная операция оказалась бы недопустимой.
Ради большей наглядности примера вся рассмотренная выше последовательность операций собрана ниже в единую программу.
// Продемонстрировать ковариантность в обобщенном интерфейсе, using System;
// Этот обобщенный интерфейс поддерживает ковариантность. public interface IMyCoVarGenIF<out Т> {
Т GetObjectO;
}
// Реализовать интерфейс IMyCoVarGenlF. class MyClass<T> : IMyCoVarGenIF<T> {
T obj;
public MyClass(T v) { obj = v; } public T GetObjectO { return obj; }
}
// Создать простую иерархию классов, class Alpha { string name;
public string GetNameO { return name; }
// ...
}
class Beta : Alpha {
public Beta(string n) : base(n) { }
// ...
}
class VarianceDemo { static void Main() {
// Создать ссылку из интерфейса IMyCoVarGenlF на объект типа MyClass<Alpha>.
// Это вполне допустимо как при наличии ковариантности, так и без нее. IMyCoVarGenIF<Alpha> AlphaRef = new MyClass<Alpha>(new Alpha("Alpha #1"));
Console.WriteLine("Имя объекта, на который ссылается переменная " +
"AlphaRef: " + AlphaRef.GetObj ect().GetName());
//А теперь создать объект MyClass<Beta> и присвоить его // переменной AlphaRef.
// *** Эта строка кода вполне допустима благодаря ковариантности. *** AlphaRef = new MyClass<Beta>(new Beta("Beta #1"));
Console.WriteLine("Имя объекта, на который теперь ссылается переменная " + "AlphaRef: " + AlphaRef.GetObj ect() .GetName());
}
}
Результат выполнения этой программы выглядит следующим образом.
Имя объекта, на который ссылается переменная AlphaRef: Alpha #1 Имя объекта, на который теперь ссылается переменная AlphaRef: Beta #1
Следует особо подчеркнуть, что переменной AlphaRef можно присвоить ссылку на объект типа MyClass<Beta> благодаря только тому, что обобщенный тип Т указан как ковариантный в интерфейсе IMyCoVarGenlF. Для того чтобы убедиться в этом, удалите ключевое слово out из объявления параметра обобщенного типа Т в интерфейсе IMyCoVarGenlF и попытайтесь скомпилировать данную программу еще раз. Компиляция завершится неудачно, поскольку строгая проверка на соответствие типов не разрешит теперь подобное присваивание.
