Хочу в классе хранить коллекцию. Раньше всегда выбирал конкретный тип - список, словарь и т. п. А сейчас вдруг задумался - может, лучше указывать что-нибудь универсальное, типа 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.если есть проперти то доступ к полю даже изнутри класса только через него
Это утверждение или рекомендация? Если первое, то это неправда. А если второе, то почему?