Скажите, пожалуйста,

Насколько предпочтительнее конструкции типа (IMyInterface)object, где мы точно уверены, что object реализует IMyInterface
конструкций типа if (object is IMyInterface), где мы не уверены что приведение выполнится?

Или по-другому: насколько просаживает производительность попытка приведения типа к интерфейсу, который объект не реализует?

Здравствуйте, Блондинко, Вы писали:

Б>Или по-другому: насколько просаживает производительность попытка приведения типа к интерфейсу, который объект не реализует?

Неужто в приложении обнаружился bottleneck на приведениях типов?
Можно ведь померять, в крайнем случае.

Идут споры о дизайне

как лучше

public class Foo: IFoo1, IFoo2
{
private ArrayList _IFoo1Impl;
private ArrayList _IFoo2Impl;

IFoo1.Method1()
{
foreach (IFoo1 implementer in _IFoo1Impl)
implementer.Method1();
}

IFoo2.Method2()
{
foreach (IFoo2 implementer in _IFoo2Impl)
implementer.Method2();
}
}

или


public class Foo: IFoo1, IFoo2
{
private ArrayList _Impl;

IFoo1.Method1()
{
foreach (object implementer in _Impl)
if (implementer is IFoo1)
((IFoo1)implementer).Method1();
}

IFoo2.Method2()
{
foreach (object implementer in _Impl)
if (implementer is IFoo2)
((IFoo2)implementer).Method2();
}
}

Мне больше нравится первый вариант, но обосновать свою точку зрения нормально не могу, разве что если производительность упадет...

Есть какие-нибудь предложения за и против?

(типизированные коллекции не предлагать — это .net 1, элементов в коллекции вряд ли будет больше десяти)

Здравствуйте, Блондинко, Вы писали:

Б>Мне больше нравится первый вариант, но обосновать свою точку зрения нормально не могу, разве что если производительность упадет...

Эти варианты имеют разное поведение. В первом случае наличие в коллекции элемента неподходящего типа будт вызывать исключение, а во втором — они будут просто пропускаться.
Если интересует именно второй вариант, то его лучше переписать через оператор as с последующей проверкой на null.

Здравствуйте, nikov, Вы писали:

N>Здравствуйте, Блондинко, Вы писали:

Б>>Мне больше нравится первый вариант, но обосновать свою точку зрения нормально не могу, разве что если производительность упадет...

N>Эти варианты имеют разное поведение. В первом случае наличие в коллекции элемента неподходящего типа будт вызывать исключение, а во втором — они будут просто пропускаться.
N>Если интересует именно второй вариант, то его лучше переписать через оператор as с последующей проверкой на null.

там есть проверка if (implementer is IFoo1) (прошу прощения, забыла отформатировать код)

Вопрос стоит исключительно о том, стоит ли хранить разные интерфейсы в разных коллекциях, если они все равно не типизированные.

Здравствуйте, Блондинко, Вы писали:

Б>Здравствуйте, nikov, Вы писали:

N>>Здравствуйте, Блондинко, Вы писали:

Б>>>Мне больше нравится первый вариант, но обосновать свою точку зрения нормально не могу, разве что если производительность упадет...

N>>Эти варианты имеют разное поведение. В первом случае наличие в коллекции элемента неподходящего типа будт вызывать исключение, а во втором — они будут просто пропускаться.
N>>Если интересует именно второй вариант, то его лучше переписать через оператор as с последующей проверкой на null.

Б>там есть проверка if (implementer is IFoo1) (прошу прощения, забыла отформатировать код)

Б>Вопрос стоит исключительно о том, стоит ли хранить разные интерфейсы в разных коллекциях, если они все равно не типизированные.

Мне тоже кажется as + проверка на нул круче )
Вообще, есть ли веские причины, почему обработка идет в одном классе? Быть может на самом деле лучше 2 класса по 1 на каждый интерфейс...

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

Здравствуйте, Блондинко, Вы писали:

Б>Идут споры о дизайне
Б>Мне больше нравится первый вариант, но обосновать свою точку зрения нормально не могу, разве что если производительность упадет...

Постараюсь помочь: производительность просядет [или может просесть] в том, что "в среднем" при вызове любого из методов первого варианта цикл гарантированно не делает ни одной лишней итерации, тогда как во втором примере это не так.

Многое зависит от того, как массивы заполнятся и используются помимо показанного — из примера не понятно, какие могут быть накладные расходы на хранение объектов в разных масссивах по сравнению с хранением в одном.

Здравствуйте, Блондинко, Вы писали:

Б>Или по-другому: насколько просаживает производительность попытка приведения типа к интерфейсу, который объект не реализует?

Ни насколько чтобы это быдо заметно. Здесь

Автор(ы): Владислав Чистяков (VladD2)
Дата: 18.12.2004
Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

довольно подробно обсасываются все моменты.
IMXO, as в c# это вообще ошибка дизайна.
Если где-то возникает код, где использование as критично, то скорее всего в этом коде тоже проблема в консерватории.

Здравствуйте, Блудов Павел, Вы писали:

БП>IMXO, as в c# это вообще ошибка дизайна.

Был бы я гуру, я бы похоливарил на эту тему )

А так просто скажу свою логику
1) () без предварительного is == семантическая связанность, надежда на какую-то логику системы, мешает повторному использованию и вообще зло
2) () и его is должны располагаться максимально близко, так как этот is только и нужен, что для этого каста, нет причин их разлучать
3) () + близко стоящий к нему is == as

Здравствуйте, Nuseraro, Вы писали:

N>3) () + близко стоящий к нему is == as

Замени-ка тут:

int Test(IConvertible x) {
  if(x is int) {
    return (int)x;
  }//if
  return 0;
}

Здравствуйте, Блудов Павел, Вы писали:

БП>IMXO, as в c# это вообще ошибка дизайна.

Почему?

Здравствуйте, _FRED_, Вы писали:

БП>>IMXO, as в c# это вообще ошибка дизайна.
_FR>Почему?
Да как-то пару раз наступил на грабли при рефакторинге своего, но давно позабытого кода.
Главное выигрыша никакого, а проблем можно поиметь. Теперь всюду где Решарпер предлагает заменить as на () меняю не задумываясь.

Здравствуйте, Блудов Павел, Вы писали:

БП>>>IMXO, as в c# это вообще ошибка дизайна.
_FR>>Почему?
БП>Да как-то пару раз наступил на грабли при рефакторинге своего, но давно позабытого кода.

То есть дело в возможности (и, к сожелению, часто используемой) не правильного, не по-месту применения as? Да, быть может. Надо было вовремя [по]читать Влада

Автор(ы): Владислав Чистяков (VladD2)
Дата: 18.12.2004
Работая над открытыми проектами, автор заметил, что операторы as и is многими программистами зачастую используются ненадлежащим образом. Результатом очередного двухчасового поиска ошибки и стала эта статья.

БП>Главное выигрыша никакого, а проблем можно поиметь. Теперь всюду где Решарпер предлагает заменить as на () меняю не задумываясь.

Да это, как мне кажется, и так должно быть видно, где что применять (если вопрос только в синтаксисе). Самая частая ошибка — нехорошая задумка, приводящая к as, тогда как можно было бы подумать-подумать и ограничиться кастом.