Пока читал про делегаты, набрёл на термины Ковариантность и Контравариантность. Почитал википедию ru.wikipedia.org) .

Цитата:

Так, если класс Cat наследует от класса Animal, то естественно полагать, что перечисление IEnumerable<Cat> будет потомком перечисления IEnumerable<Animal>. Действительно, «список из пяти кошек» — это частный случай «списка из пяти животных».

Продолжаю мысль: В список животных можно занести кошку, а в список кошек занести собаку нельзя.

Цитата:

Так, если класс String наследует от класса Object, а делегат Action<T> определён как метод, принимающий объект типа T, то Action<Object> наследует от делегата Action<String>, а не наоборот. Действительно, если «все строки — объекты», то «всякий метод, оперирующий произвольными объектами, может выполнить операцию над строкой», но не наоборот.

Не понятен смысл "произвольными объектами". Это какими?

Пытаюсь продолжить мысль: метод, оперирующий строками, не может выполнить операцию над ____ И, не знаю - что сюда вставить...

P.S. То ли уже поздно, и просто надо лечь и поспать...

S-type
всякий метод, оперирующий произвольными объектами

Включает в себя клон(), геттип(), тостринг() и т.д.
Все эти операции реализованы со строками.

S-type
метод, оперирующий строками, не может выполнить операцию над

не строками
Это же строго типизировано)





Исправлено 1 раз(а). Последнее : Аспид, 08.03.17 10:36

S-type
Не понятен смысл "произвольными объектами". Это какими?

Любыми. Числами, Датами, Животными, Кошками...

S-type
Пытаюсь продолжить мысль: метод, оперирующий строками, не может выполнить операцию над ____ И, не знаю - что сюда вставить...

Числами, Датами, Животными, Кошками... В общем ничем кроме строк. Если бы тип System.String не был запечатанным (sealed), то такой метод мог бы работать и с типами-наследниками. Скажем метод работающий с "Животными" может работать и с Кошками и с Собаками, но не может работать со Строками, Числами, Датами...

Аспид
Это же строго типизировано)

Ну, как раз таки, контравариантность и позволяет смягчить строгую типизацию и использовать более универсальный (базовый) тип, чем указанный.

Igor Korolyov
метод работающий с "Животными" может работать и с Кошками и с Собаками, но не может работать со Строками, Числами, Датами...

Точно! Надо переделать определение контравариантности на котов и животных. Подставляем вместо string - Cat, вместо object - Animal:

Так, если класс Cat наследует от класса Animal, а делегат Action<T> определён как метод, принимающий объект типа T, то Action<Animal> наследует от делегата Action<Cat>, а не наоборот. Действительно, если «все коты — животные», то «всякий метод (например, сфотографировать), оперирующий произвольными животными, может выполнить операцию над котом (весь инет завален котиками)», но не наоборот. Метод, оперирующий котами (например, подержать на руках), не может выполнить операцию над любым животным (например, слоном).

По сути правильно то описано, только меня коробит от фразы "Action<Animal> наследует от делегата Action<Cat>".
Ничего они не "наследуют". Просто при связывании делегата с методом действуют более мягкие правила - не обязательно 100% совпадение сигнатуры... Кстати, это работает и без generic-ов. Для обычных делегатов (тех же event-ов для визуальных компонент - KeyPress или KeyDown или даже Load можно "зарядить" на один и тот же метод-обработчик, хотя формально у них разные "сигнатуры") тоже применимо подобное "смягчение".

(подумал, контрвариантный [тензор], подумал, началась голимая физика/математика )

Igor Korolyov
По сути правильно то описано, только меня коробит от фразы "Action<Animal> наследует от делегата Action<Cat>".
Ничего они не "наследуют". Просто при связывании делегата с методом действуют более мягкие правила - не обязательно 100% совпадение сигнатуры...

Мне кажется, тут под "наследует" подразумевается не наследование в терминах C#, а наследование в более общем смысле - "передача каких то прав (возможностей)", а именно - передача возможности работы с предками класса. Отсюда вытекает определение:

Цитата:

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

Хотя, на мой взгляд, определение хоть и верное, но мало что в мозгах проясняющее. IMHO, самое правильное будет:

Цитата:

Контравариантность позволяет присвоить делегату (привязать к делегату) метод, типом параметра которого служит класс, являющийся базовым (родительским) для класса, указанного в объявлении делегата. Контравариантность позволяет определить единственный делегат, который указывает на методы, в качестве параметра принимающие класс или его родительские классы.

Тут сразу понятно, для чего вся эта "пертушка".

Igor Korolyov
Кстати, это работает и без generic-ов. Для обычных делегатов (тех же event-ов для визуальных компонент - KeyPress или KeyDown или даже Load можно "зарядить" на один и тот же метод-обработчик, хотя формально у них разные "сигнатуры") тоже применимо подобное "смягчение".

Вот то же для меня загадка. Простой делегат (не обобщённый) он одновременно и ковариантный и контравариантный. А обобщённый по умолчанию инвариантный, но если явно указать in или out, может быть либо ковариантным либо котравариантным, одновременно быть ковариантным и контравариантным (как необобщённый) не может. Почему? Зачем? Где собака порылась?

Ты не прав. Эти "вариантности" применяются к РАЗНЫМ типам: Ковариантность - к возвращаемому типу, контравариантность - к принимаемым (типам параметров).
Это так и в generic интерфейсах (т.к. там есть методы которые что-то возвращают и что-то принимают) и в делегатах (как generic так и обычных - но для обычных нельзя управлять ко- и контра-вариативностью, она работает автоматически и только для "связывания" с методами, но не для присвоения экземпляров переменным "чуть другого типа").

Естественно что и интерфейс и делегат могут одновременно быть и ко- и контра-вариантными, т.к. это аспекты применимые к разным типам. Естественно один и тот же параметр типа не может быть одновременно и ко- и контра- вариантным (это формальное ограничение, по сути, если бы оно было допустимо, то оно сделало бы этот тип ИНвариантным - т.е. можно было бы использовать только его, ни "наследники", ни "предки" не были бы допустимы).
Пример одновременно ко- и контра- вариантного делегата это семейство делегатов Func<T1,T2,...TResult> Все его T* параметры контравариантны (это типы для параметров привязываемого метода), а TResult ковариантен (это тип для возвращаемого значения).

Igor Korolyov
Естественно что и интерфейс и делегат могут одновременно быть и ко- и контра-вариантными, т.к. это аспекты применимые к разным типам. Естественно один и тот же параметр типа не может быть одновременно и ко- и контра- вариантным (это формальное ограничение, по сути, если бы оно было допустимо, то оно сделало бы этот тип ИНвариантным

Золотые слова, Юрий Бенедиктович. (с) Наша Раша

Спасибо за разъяснения. Буду курить мануалы дальше.