Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате
Форум программистов > Общие вопросы по .NET и C# > как указать что член класса должен


Автор: Kefir 28.6.2007, 12:34
САБЖ.

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

class Foo {
public List<object> Items; // надо чтобы все итемы реализовывали интерфейс IMyInterface
}


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

Автор: HalkaR 28.6.2007, 12:54
Kefir, имхо public List<IMyInterface> Items - самый простой способ. Чем он плох?

Автор: Kefir 28.6.2007, 13:59
гм.... хорошо....
делаю 
Цитата(HalkaR @  28.6.2007,  12:54 Найти цитируемый пост)
List<IMyInterface>


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

class MyClass : IMyInterface { ... }

Foo foo = new Foo();
List<MyClass> list = new List<MyClass>();
foo.Items = list;

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

List<IMyInterface> list = new List<IMyInterface>();
foo.Items = list;

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

Автор: Void 28.6.2007, 14:12
Kefir, то, что ты хочешь, называется ковариантность коллекций и достичь этого в шарпе, увы, невозможно.
Цитата(Kefir @  28.6.2007,  15:59 Найти цитируемый пост)
Но ведь тогда читабельность кода страдает (не видно какой на самом деле класс в листе)... 

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

P.S. При том, что массивы-то ковариантны:
Код
class MyClass : IMyInterface { }
...
IMyInterface[] a = new MyClass[10]; // perfectly OK

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

Автор: Kefir 28.6.2007, 14:36
Цитата(Void @  28.6.2007,  14:12 Найти цитируемый пост)
ковариантность коллекций

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


Цитата(Void @  28.6.2007,  14:12 Найти цитируемый пост)
Раз ты завёл интерфейс, значит в этом месте нас не должно волновать

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

class Catalogue : UserControl
{
  List<ICatalogueItem> Items;
}

interface ICatalogueItem
{
  string CatalogueText { get; }
}

class Drink : ICatalogueItem {
  public string Name;
  public string Vol;
  // etc.  

  public string CatalogueText { get { return this.Name; } }
}

class Food : ICatalogueItem {
  public string Name;
  public int Callories;
  //etc.

  public string CatalogueText { get { return this.Name; } }
}

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

List<Drink> drinks = Menu.GetAllTheDrinks();
catalogue1.Items = drinks;

// ...

List<Food> foods = Menu.GetAllTheFood();
catalogue1.Items = foods;

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

Добавлено через 7 минут и 50 секунд
Цитата(Void @  28.6.2007,  14:12 Найти цитируемый пост)
Раз ты завёл интерфейс, значит в этом месте нас не должно волновать, что под ним прячется конкретно.

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

Автор: mihryak 29.6.2007, 23:34
можно выкрутиться так (используя ковариантность массивов)
Код

            List<Drink> drinks = Menu.GetAllTheDrinks();
            catalogue1.Items.AddRange(drinks.ToArray());

            // ...

            List<Food> foods = Menu.GetAllTheFood();
            catalogue1.Items.AddRange(foods.ToArray());

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

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

            catalogue1.Items = new List<ICatalogueItem>(drinks.Count);

Автор: Kefir 30.6.2007, 00:17
Цитата(mihryak @  29.6.2007,  23:34 Найти цитируемый пост)
catalogue1.Items.AddRange(foods.ToArray());

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

            catalogue1.Items = new List<ICatalogueItem>(categories.ToArray());

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

Добавлено через 2 минуты и 11 секунд
 smile 
хехе. ввёл в гугль строку "ковариантность коллекций" и эта тема - первый результат ))
http://www.google.ee/search?q=%D0%BA%D0%BE%D0%B2%D0%B0%D1%80%D0%B8%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D1%8C+%D0%BA%D0%BE%D0%BB%D0%BB%D0%B5%D0%BA%D1%86%D0%B8%D0%B9&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-US:official&client=firefox-a

Автор: Gelis 30.6.2007, 12:47
Код

class Foo<T> where T : IMyInterface
{
    public List<T> Items;
}

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

http://www.ibm.com/developerworks/ru/library/j-jtp01255/

Автор: Idsa 6.7.2007, 20:23
Я вот никак не могу разобраться с выводом по первому примеру в указанной anthony ссылке:
Цитата

List<Integer> li = new ArrayList<Integer>();
List<Number> ln = li; // не верно 
ln.add(new Float(3.1415));

Поскольку ln имеет тип List<Number>, добавление Float к нему выглядит совершенно легальным. Но если ln присвоить li, то это нарушило бы независимость от типа, который явно указан при определении li (что li - это список целых чисел), вот почему родовые (generic) типы не могут быть ковариантными.

В чем смысл?

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

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

Автор: Idsa 7.7.2007, 21:39
Цитата(Void @  6.7.2007,  20:39 Найти цитируемый пост)
Когда мы добавим в ln объект типа Float, окажется, что li содержит и Integers, и Floats.

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

Цитата(Void @  6.7.2007,  20:39 Найти цитируемый пост)
 И если самой коллекции может быть и всё равно, то код, работающий с ней, слегка удивиться, получив вещественное число там, где должны быть только целые.

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

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

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

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)