Пользовательская коллекция с использованием IEnumerable vs ICollection vs IList - программирование

Пользовательская коллекция с использованием IEnumerable vs ICollection vs IList

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

Я немного запутался в том, что если я иду с IEnumerable<T>, мне может потребоваться объявить объект для фактического хранения коллекции, как в этом случае _list.

public class GenericCollection<T> : IEnumerable<T>
{
    private List<T> _list;
    //...
}

Но если я иду с ICollection<T> или IList<T>, мне не требуется объявлять объект List, поскольку он неявно доступен.

public class GenericCollection<T> : IList<T>
{
    // no need for List object
    //private List<T> _list; 
    //...
}

В чем разница между этими двумя подходами в отношении производительности?

В этом сценарии каждый из них предпочтительнее, особенно когда речь идет о создании собственной коллекции. Меня интересует сборка легкого веса с хорошей производительностью. Я думаю, что это может быть достигнуто с помощью IEnumerable<T>, но как именно с некоторыми сильными причинами пойти с ним?

Я просмотрел некоторые существующие сообщения, но никто не дает требуемую информацию.

Возвращение 'IList' против 'ICollection' vs 'Collection'

4b9b3361

Ответ 1

IEnumerable, ICollection и IList (как правило, любой тип с префиксом I) - это просто интерфейсы, Они позволяют вам разоблачить, что будет делать ваш класс, но в отличие от того, если вы наследуете класс, интерфейсы не предоставляют вам реализацию по умолчанию любого из вещи, которые они говорят, что вы должны делать.

Что касается выбора интерфейса, здесь краткое руководство:

  • An IList - это ICollection, к которому можно получить доступ по индексу.
  • An ICollection является IEnumerable с легким доступом к вещам типа Add, Remove и Count.
  • IEnumerable - это все, что можно перечислить, даже если список этих вещей не существует до тех пор, пока вы не перечислите его.

Некоторые классы, которые вы, возможно, захотите расширить (или сохраните как частное поле, выполняющее большую часть логики) для вашей коллекции, это List<T>, Collection<T>, (который реализует IList<T>, но с более легким доступом к переопределению реализации, см. Сбор <T> против List <T> то, что вы должны использовать на своих интерфейсах? для больших различий между этими двумя) ObservableCollection<T> или коллекций, которые а не списки, например Dictionary<T, U> и HashSet<T>. Для получения дополнительной информации о любом из них, посмотрите документацию MSDN в классе.

Ответ 2

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

Производительность, я сомневаюсь, что это будет иметь большое значение, сосредоточьтесь на том, что вам нужно функционально. Единственный способ узнать наверняка - это измерить.

Ответ 3

Производительность вряд ли будет зависеть от того, какие интерфейсы реализованы. Это зависит от того, сколько инструкций требуется процессору для достижения определенной цели. Если вы реализуете IEnumerable и обертываете List, вы, вероятно, закончите писать методы Add/Remove/this [], которые просто распространяют вызовы в List, что добавит служебные данные о производительности. Следовательно, хотя я не принимал никаких измерений, подход наследования, вероятно, будет очень немного быстрее.

Однако такие данные обычно имеют значение только для приложений реального времени с крайней необходимостью сохранять каждый возможный цикл ЦП. У Эрика Липперта есть отличная статья о том, чтобы обратить внимание на такие детали: http://blogs.msdn.com/b/ericlippert/archive/2003/10/17/53237.aspx. Как правило, вы, вероятно, будете лучше использовать подход, который лучше подходит для бизнес-логики и архитектуры вашего приложения, а не характеристик производительности.