Хочу в классе хранить коллекцию. Раньше всегда выбирал конкретный тип - список, словарь и т. п. А сейчас вдруг задумался - может, лучше указывать что-нибудь универсальное, типа IEnumerable?

Ну, выбрал IEnumerable. В конструкторе присваиваю переменной этой коллекции экземпляр списка. Но столкнулся с тем, что теперь при обращении к этой коллекции, когда я, например, хочу заполнить её элементами через последовательное добавление этих элементов (как Add в списке), я должен привести её к конкретному типу. Т. е. если хочу добавлять элементы через Add, то надо приводить к списку и затем вызывать Add.

В связи с этим возникла догадка, что я неправильно использую интерфейс. Т. е. получается, что данные хранить лучше не в интерфейсных типах, а в конкретных. А интерфейсные типы использовать, например, в параметрах функций для их, функций, большей универсальности. И вообще, интерфейс IEnumerable нужен не для редактирования элементов, а для их чтения через какой-нибудь foreach. Т. е., если где-то в функции идёт последовательная обработка элементов коллекции, то IEnumerable как раз подойдёт в качестве типа параметра. Правильно я рассуждаю?

SolYUtoruser7320,

Надо различать реализацию и интерфейс класса. Внутри класса надо работать с тем, что удобнее: словарь, список и т.д. А вот принимать на вход и отдавать на выход можно и интерфейсами.
Ну да, это я и имел ввиду. А "принимать" и "отдавать" можно же только функциями (в которые входят и конструкторы)? Вот я и говорю, что использовать интерфейсы лучше в параметрах функций, а хранить данные - не в интерфейсах, а в конкретных типах.

Изопропилuser7320Т. е. получается, что данные хранить лучше не в интерфейсных типах, а в конкретных
IEnumerable<T> не рассматривал?
Так я изначально его и подразумевал. Про конкретику я имел ввиду List<T>, Array<T> и т. п. вместо IEnumerable<T>.

skyANAAntonariy...в целом ахинея. Прочитай какую-нибудь теорию по ООП...+1



А какой смысл этого кода? Ведь одно из назначений интерфейса - обобщение. Т. е. чтобы я не менял код, скажем, функции (а у вас что геттер, что Add - функции) при изменении типа коллекции, с которой работает эта функция. А у вас если я у поля HarvestedFoods заменю тип списка на какую-нибудь другую коллекцию, где нет Add, то мне придётся и код функции Add менять. Поэтому я и говорил, что если функция использует коллекцию так, что эта функциональность покрывается интерфейсом, то надо использовать интерфейс, а если не покрывается, то использование интерфейса бессмыслено. Т. е. если я в функции перебираю элементы через foreach, то можно использовать IEnumerable, т. к. все коллекции, реализующие IEnumerable, реализуют и foreach. А если я в функции добавляю элементы по одному через Add, то тут либо другой интерфейс (ICollection, как мне правильно подсказали), либо конкретный тип коллеции, который эту функциональность реализует.

Наверное, в вашем примере правильнее было бы заменить IEnumerable на ICollection, но тогда смысла в отдельной функции Add нет.

skyANAuser7320Наверное, в вашем примере правильнее было бы заменить IEnumerable на ICollection, но тогда смысла в отдельной функции Add нет.Термин инкапсуляция Вам о чём-нибудь говорит?
Вы пытаетесь скрыть реализацию добавления элемента в поле-коллекцию класса? Тогда понятно. Только всё равно, не совсем удачная реализация - если заменять тип коллеции, то и реализацию тоже придётся менять. И имеет ли смысл такая мелочная инкапсуляция?

skyANAAntonariy...в целом ахинея. Прочитай какую-нибудь теорию по ООП...+1



Тогда вот ещё такой вопрос по этому коду и вообще. В методах класса лучше использовать геттеры и сеттеры для полей-данных класса, или сами эти поля-данные? Ну, т. е. конкретно в этом примере понятно, что по смыслу надо использовать harvestedFoods вместо HarvestedFoods. А вообще? Есть ли смысл использовать геттеры и сеттеры внутри класса, или они только для внешних клиентов?

И ещё вопрос по коду Скайана. Будет лучше или хуже, если вместо




сделать




?

Denis.если есть проперти то доступ к полю даже изнутри класса только через него
Это утверждение или рекомендация? Если первое, то это неправда. А если второе, то почему?

Ну, вот я только могу представить, если свойства содержат логику валидации полей, как в MVVM через IDataErrorInfo, то, пожалуй, стоит даже внутри класса к полям через свойства обращаться, если могут быть какие-то изменения этих полей.

Вобщем, как и почти всегда, вы не даёте конкретного ответа (вздыхает). Как я понял, для каждого случая лучше что-то своё. Нужно каждый раз анализировать ситуацию. Общего правила нет... Вот так и утекает время и внимание на мелочи (вздыхает).

...(вздыхает ещё раз)

Алексей КDenis.делай так чтобы торчали интерфейсыТорчащий наружу IEnumerable может выйти боком в условиях многопоточности.
Блин, я уже сделал айэнумерейбл!

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

Denis.Алексей К,
конструкция "public int MyValue;" - для меня вообще загадочна.
Допустим есть проперти с паблик сеттером, допустим вы извне меняете естественно через сеттер, а изнутри класса меняете через поле. У вас в проперти инвалид значение и вы хотите поставить брейкпоинт чтобы поглядеть колстек. Что будете делать? И почему сразу изнутри класса не юзать гетеры сетеры?(про вырожденные случаи не надо). Вообще вопрос настолько очевидный, что его даже как-то странно обсуждать.
Ну, выше же говорили про производительность, что это лишний вызов метода, который где-то на порядок медленнее прямого обращения к полю (судя по старым тестам ещё времён фреймворк 1-1.1, может, 2). Поэтому, скажем, обращение к полю через геттер внутри класса лучше всё же заменить на прямое обращение к полю в задачах, где слишком много таких обращений (всякие итерации по сассивам и пр.). Правильно я говорю, да?

user7320Алексей Кпропущено...
Торчащий наружу IEnumerable может выйти боком в условиях многопоточности.
Блин, я уже сделал айэнумерейбл!

А можете пример привести, когда в условиях многопоточности айэнумерейбл может вылезти боком и почему?
Здесь http://msdn.microsoft.com/en-us/library/system.collections.ienumerable.aspx
и здесь http://msdn.microsoft.com/en-us/library/9eekhta0.aspx вообще ничего про потоки не написано (искал по "thre" по странице).

Алексей Кuser7320пропущено...

Блин, я уже сделал айэнумерейбл!

А можете пример привести, когда в условиях многопоточности айэнумерейбл может вылезти боком и почему?Наружу торчит Enumerable. Вы не знаете что за коллекция за ним скрыта. Делаете по ней foreach. При этом оказывается, что это List, в который добавляет элементы другой поток.

Если наружу торчит что-то неизменяемое (массив, ReadOnlyCollection и т. п.) как-то спокойнее.
Ну, наверное есть же какие-нибудь механизмы, которые могут извещять всякий поток, работающий с коллекцией, что другой поток в данный момент изменяет её? Или, даже если и есть такие механизмы, то они ничего не дадут?

enigmaticПочему тогда не писать сразу на ассемблере, если производительность так критична?
Не стоит заморачиваться на этих мелких оптимизациях, если точно не видно, что есть существенное падение производительности.
http://ericlippert.com/2012/12/17/performance-rant/
А зачем тормозить на ровном месте? Если Сишарп не самый быстрый язык в мире, это не значит, что нужно делать его медленнее, чем он есть. И если у меня какой-то метод слишком много обращается к полям своего класса, то почему бы сразу не сделать обращение к этим полям непосредственным, а не через геттеры? Сразу, а не после тестирования производительности и обнаружения очевидных просадок на тех местах, где вы их и ожидали ещё при написании кода.