САБЖ.

если развёртнуто, то допустим имеем класс


Вот, собственно и всё. Как писать объявление? Просто public List<IMyInterface> Items?.. или надо сделать что-то навроде проперти, где в set проверять поддурживается ли интерфейс?..

Kefir, имхо public List<IMyInterface> Items - самый простой способ. Чем он плох?

гм.... хорошо....
делаю 


тогда например есть код:

тогда при компайле будет сообщение о том, что, мол, cannot implicitly convert type List<MyClass> to List<IMyInterface>. ведь MyClass имплементирует IMyInterface, тогда почему нельзя так? Или надо что-то где-то дописать? Или вообще положено писать так:

? Но ведь тогда читабельность кода страдает (не видно какой на самом деле класс в листе)...

Kefir, то, что ты хочешь, называется ковариантность коллекций и достичь этого в шарпе, увы, невозможно.

Раз ты завёл интерфейс, значит в этом месте нас не должно волновать, что под ним прячется конкретно.

P.S. При том, что массивы-то ковариантны:

Вот такой нелогичный... не язык даже, а рантайм.

Это сообщение отредактировал(а) Void - 28.6.2007, 14:15

  ээээ... мой уши в первый раз слышат это... ну ничего. теперь хоть знаю.



гм.... ну я бы не сказал.
в общем суть проблемы от начала до конца.
у меня есть различные классы, которые будут реализовывать ICatalogueItem. есть юзер контрол, который показывает List<ICatalogueItem>. То есть примерно:

так вот. в итоге где-то я буду получать (например после общения с БД) что-нибудь а-ля:

и чтоже теперь GetAllTheDrinks(); и GetAllTheFood(); должны будут возвращать List<ICatalogueItem> вместо логичных List<Drink> и List<Food>?..

Добавлено через 7 минут и 50 секунд

забыл - меня не должно волновать в самом юзер контроле Catalogue (в данном случае) какой класс мне дают на Items - главное чтобы класс реализовывал ICatalogueItem. Это же имхо для того и сделано, чтобы там не волноваться. А снаружи-то этого класса по сути Items назначаются так как хочешь (хоть List<Tralala> или List<Ugabuga> - главное чтобы Tralala : ICatalogueItem и Ugabuga : ICatalogueItem). Вот как в том же DataGridView - дата сорц может быть любой класс, реализовавший IList (ну или что-то вроде IList). Ну так я же беру и подаю ему DataTable или DataView, а не IList. Или я снова чего-то не понял? Почему у меня в первом после и упоминается object - потому что DataSource тоже object 

можно выкрутиться так (используя ковариантность массивов)

рефлектором не смотрел, но вроде как серьёзных преобразований при этом не должно происходить

ПС. Не забываем выставлять заранее размер коллекции в catalogue1

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

изменил только потому, что при AddRange надо сперва сделать Clear. но это мелочи, главное то, что setter у Items не происходит, где мне надо произвести некоторые обновления.

Добавлено через 2 минуты и 11 секунд
  
хехе. ввёл в гугль строку "ковариантность коллекций" и эта тема - первый результат ))
гугль

Кстати третья ссылка в Гугль достаточно ясно описывает эту проблему в Java:

ковариантность коллекций

Я вот никак не могу разобраться с выводом по первому примеру в указанной anthony ссылке:

В чем смысл?

List<T> — ссылочный тип. Если Integer — подтип Number и List<Integer> — подтип List<Number>, то должно быть возможно неявное приведение одного к другому. Таким образом, если ln присвоить li, то объявленный тип ln будет List<Number>, а фактический — List<Integer>. Когда мы добавим в ln объект типа Float, окажется, что li содержит и Integers, и Floats. И если самой коллекции может быть и всё равно, то код, работающий с ней, слегка удивиться, получив вещественное число там, где должны быть только целые.

Надо посмотреть, как это разрулено в Scala. Я только помню, что там ковариантность и контравариантность обобщённых типов указывается явно.

Видимо, "окажется, что ln"?


А чего это он удивится? Тип-то Number.

Idsa, ln и li ссылаются на один и тот же объект, фактический тип которого — List<Integer>.

Кстати, глянул на коллекции в Scala. Вопрос решается вполне логично: ковариантны только неизменяемые коллекции.