Что такое Name<T>

@SocialEngineer · Регистрация: 14.04.2012

Author24 — интернет-сервис помощи студентам

Здравствуйте,читаю Герберта Шилдта,в главе про многопоточное программирования он во всю использует такие делегаты/методы с названием Name<T>,где T -какой-нибудь тип(bool,int)

Совсем не понимаю,что это такое,ведь в главе про обобщения не было этого,хотя я догадываюсь,что принцип тот же.
Помогите,я привык вникать в текст,а тут такое.

А так же он в этих <> использует такие операторы как in,что они делают?
Пример:

C#

1	public delegate void Action<in T>(T obj)

@kolorotur · 12.06.2012, 02:15

Сообщение от SocialEngineer

Совсем не понимаю,что это такое

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

C#

1	delegate void Action<T>(T obj);

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

C#

1
2
3

void Foo(int x) {}
void Foo(double x) {}
void Foo(BlaBlaClass x) {}

И так далее.

Сообщение от SocialEngineer

А так же он в этих <> использует такие операторы как in,что они делают?

Начиная с четвертой версии фреймворка у интерфейсов и делегатов появилась такая штука, как вариантность. В этом месте у многих сносит крышу.
Интерфейсы и делегаты могут быть ковариантными и контрвариантными (covariant/contravariant. Я не знаю как правильно по-русски это дело называется, может кто поправит).
Если имеется класс А, от которого наследуется класс B, то интерфейс или делегат X<B> является ковариантным в том случае, если переменную типа X<B> можно неявно привести к типу X<A>:

C#

1 2	X<string> x = ... X<object> y = x; // Если компилятор такое позволяет, то интерфейс X<T> является ковариантным

Контрвариантность - это наоборот, возможность ссылку на обобщенный интерфейс/делегат с типом А привести к типу В:

C#

1 2	X<object> x = ...; X<string> y = x; // Если компилятор такое позволит, то интерфейс X<T> является контрвариантным.

Параметр in позволяет интерфейсу быть контрвариантным, то есть тип, обозначенный этим оператором, может в делегат/метод подаваться только в качестве аргумента, но не быть возвращаемым значением:

C#

1
2
3

delegate void Action<in T>(T obj); // OK
delegate T Action<in T>(); // NOT OK
delegate T Action<in T>(T obj); // NOT OK

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

C#

1
2
3

delegate T Action<out T>(); // OK
delegate T Action<out T>(T obj); // NOT OK
delegate void Action<out T>(T obj); // NOT OK

@Соколиный глаз · 27.02.2019, 17:02

Сообщение от kolorotur

Параметр in позволяет интерфейсу быть контрвариантным

Ковариантность - это я ещё могу придумать практическое применение. Но зачем контрвариантность? Мне бы хотелось увидеть примеры, где бы это могло было быть полезным? Желательно, жизненные, как сейчас говорит молодежь.

@kolorotur · 27.02.2019, 21:26

Сообщение от Соколиный глаз

Но зачем контрвариантность? Мне бы хотелось увидеть примеры, где бы это могло было быть полезным? Желательно, жизненные, как сейчас говорит молодежь.

Ну самый распространенный пример, пожалуй, — это контрвариантность делегатов.
Почему МС рекомендует всем событиям давать сигнатуру вида void (object, TEventArgs), где TEventArgs : EventArgs?
Потому, что делегаты контрвариантны в параметрах. Это значит, что если у вас есть метод void Foo(object sender, EventArgs e), то вы этот метод можете подписать на любое событие, вне зависимости от конкретного типа второго параметра. До тех пор, пока этот параметр наследуется от EventArgs.

С интерфейсами примерно то же самое: контрвариантность позволяет передавать тип с более широким функционалом в компонент, которому нужен более узкий функционал.
Простой пример из всеми нами горячо любимых игрушек.
Инвентарь:

C#

abstract class Item { }
abstract class Weapon : Item { }
abstract class Armor : Item  { }
abstract class Food : Item { } 
class Sword : Weapon { }
class Dagger : Weapon { }
class Chestplate : Armor { }
class Bracers : Armor { } 
class Apple : Food { }
class Bread : Food { }

Интерфейс, описывающий скупщика предметов:

C#

IBuyer<in T> where T : Item
{
   decimal Buy(T item);
}

Где-то в дебрях классов, представляющих правила игры, есть метод Sell, продающий определенный предмет определенному продавцу:

C#

decimal SellArmor(IBuyer<Armor> armorMerchant, Armor armor)
{
   return armorMerchant.Buy(armor);
}

Ну и вполне очевидно, что благодаря контрвариантности можно с помощью этого метод продать броню скупщику всего подряд:

C#

class GeneralVendor : IBuyer<Item>
{
   public decimal Buy(Item anything)
   {
      return PriceList[anything];
   }
}
 
GeneralVendor vendor = GeneralStore.Vendor;
Player.Inventory.Gold += RuleBook.SellArmor(vendor, Inventory.BrokenArmor);

@Соколиный глаз Alvin Seville 343 / 273 / 134 Регистрация: 25.07.2014 Сообщений: 4,537 Записей в блоге: 9
	27.02.2019, 17:02	3
	Сообщение от kolorotur Параметр in позволяет интерфейсу быть контрвариантным Ковариантность - это я ещё могу придумать практическое применение. Но зачем контрвариантность? Мне бы хотелось увидеть примеры, где бы это могло было быть полезным? Желательно, жизненные, как сейчас говорит молодежь. 0

	27.02.2019, 21:26