Понимание интерфейсов

Question

У меня есть метод класса, который возвращает список сотрудников, с которыми я могу перебирать. Какой лучший способ вернуть список? Обычно я просто возвращаю ArrayList. Однако, как я понимаю, интерфейсы лучше подходят для этого типа действий. Какой интерфейс лучше всего использовать? Кроме того, почему лучше возвращать интерфейс, а не реализацию (скажем, объект ArrayList)? Мне кажется, это намного больше работы.

Answer 1

Лично я бы использовал Список для создания списка на бэкэнде, а затем использовал бы IList при возвращении. Когда вы используете интерфейсы, это дает вам гибкость для изменения реализации без необходимости изменять, кто использует ваш код. Если вы хотите использовать ArrayList, это будет неуниверсальный IList .

Answer 2

@ Джейсон

Вы также можете вернуть IList <>, потому что массив фактически реализует этот интерфейс.

Answer 3

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

Имея это в виду, интерфейс работает для принятия элемента в качестве аргумента. Если параметр функции вызывает массив или ArrayList, это единственное, что вы можете передать ему. Если параметр функции вызывает IEnumerable, он будет принимать как и ряд других объектов. Это более полезно

Однако возвращаемое значение работает наоборот. Когда вы возвращаете IEnumerable, единственное, что вы можете сделать, это перечислить его. Если у вас есть список List и вы возвращаете его, тогда код, который вызывает вашу функцию, также может легко выполнить ряд других действий, например, получить счетчик.

Однако я едиен с теми, кто советует вам уйти от ArrayList. Дженерики намного лучше.

Answer 4

Есть ли причина, по которой коллекция должна быть заказана? Почему бы просто не вернуть IEnumerable<Employee>? Это дает необходимый минимум - если позже вы захотите какую-то другую форму хранения, такую ​​как Сумка, Набор, Дерево или еще что-то, ваш контракт останется без изменений.

Answer 5

Если все, что вы делаете, это итерация по списку, вы можете определить метод, который возвращает список как IEnumerable (для .NET).

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

Answer 6

Лучший способ сделать что-то подобное - это вернуть, как вы говорите, список, желательно с использованием дженериков, поэтому это будет список <Employee>.

Возвращение списка, а не ArrayList означает, что если позже вы решите использовать, скажем, LinkedList, вам не придется изменять какой-либо код, кроме того, где вы создаете объект для начала (то есть вызов в "новый ArrayList ())".

Answer 7

На самом деле вы не должны возвращать List, если это фреймворк, по крайней мере, не задумываясь, рекомендуемый класс для использования - это Collection. Класс List имеет некоторые улучшения производительности за счет проблем с расширяемостью сервера. На самом деле это правило FXCop.

У вас есть причина для этого в этой статье

Answer 8

Интерфейс - это, по сути, контракт, что у класса есть определенные методы или атрибуты; программирование в интерфейсе, а не в прямой реализации, позволяет создавать более динамичный и управляемый код, поскольку вы можете полностью менять реализации, пока сохраняется «контракт».

В случае, который вы описываете, передача интерфейса не дает вам особого преимущества, если бы это был я, я передал бы ArrayList с универсальным типом или передал бы сам Array: list.toArray ()

Answer 9

Вы не говорите, на каком языке вы говорите, но в чем-то .NETish, тогда не нужно больше возвращать IList, чем List или даже ArrayList, хотя простое упоминание этого устаревшего класса заставляет меня думать Вы не говорите о .NET.

Answer 10

Интерфейс - это контракт между реализацией и пользователем реализации.

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

Он также позволяет нескольким реализациям использовать один и тот же интерфейс, чтобы пользователи могли повторно использовать код, взаимодействующий с интерфейсом.