"Не выставляйте общий список", зачем использовать коллекцию <T> вместо списка <T> в параметре метода

Я использую FxCop, и он показывает предупреждение для "Не выставлять общий список", который предлагает использовать Collection<T> вместо List<T>. Причина, по которой это предпочтительнее, я знаю все это, как упоминалось в этом сообщении SO и MSDN и еще много статей, через которые я прошел.

Но мой вопрос в том, что у меня есть несколько методов, которые делают так много тяжелых вычислений, и методы принимают параметры List<T>, которые должны быть более быстрыми и хорошими с точки зрения производительности. Но FxCop предупреждает об этом, а также. Таким образом, один из вариантов заключается в том, что я должен объявить параметр как Collection<T>, а затем использовать ToList() внутри метода, а затем использовать его.

Итак, какой из них оптимизирован?

"Подавить предупреждение для этого случая" ИЛИ "использовать Collection<T> в параметре, а затем использовать ToList() внутри самого метода".

Ответ 1

Правила анализа кода /FxCop были написаны для поддержки создателей фреймворков (Microsoft создает множество фреймворков). Структура используется внешними сторонами, и вы должны быть осторожны при разработке открытого интерфейса. Если вы не пишете фреймворк, который будет использоваться внешними сторонами, вы можете просто игнорировать правила, которые не дают вам ценности.

Однако одна из причин, по которой это правило существует, заключается в том, что разоблачение коллекций в классе несколько сложно. Часто элементы в коллекции принадлежат содержащему классу, и в этом случае вы нарушаете инкапсуляцию, если вы разрешаете клиентам изменять коллекцию, используемую для хранения агрегированных элементов. Вернув List<T>, вы разрешаете клиентам изменять коллекцию различными способами. Но часто вы хотите отслеживать элементы в коллекции. Например. добавление нового элемента может потребовать некоторую дополнительную учетную запись в содержащем классе и т.д. Вы теряете этот тип контроля, когда возвращаете List<T>, если, конечно, вы не делаете копию, когда вы ее возвращаете (но тогда клиент должен понимать, что они только получают копия коллекции и модификации будут проигнорированы).

В целом вы, вероятно, можете улучшить свой дизайн класса, избегая раскрытия таких классов, как List<T>, и более подробно о том, как агрегированные элементы могут быть добавлены, изменены и удалены. Но если вы спешите и просто хотите выкопать какой-то код, то использование List<T> может быть именно тем, что вам нужно для выполнения этой работы.

Ответ 2

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

Ответ 3

ИМХО ваша интерпретация "Не выставляйте общий список", который предлагает использовать коллекцию вместо списка ". Является недействительным.

Критическое различие между сборником и списком состоит в том, что элементы в списке упорядочены. Некоторые методы могут требовать, чтобы прошедшие элементы имели порядок. Затем мы должны использовать в параметре список.

Ключом к пониманию поставленного предупреждения является то, что вместо конкретного класса List<T> следует использовать интерфейс IList<T>.

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

Заключение параметров метода должно быть абстрактным, насколько это возможно.

Ответ 4

Вы должны использовать тип, наиболее подходящий для ваших целей (и, при необходимости, подавлять предупреждение). Если вы передаете кучу предметов, а порядок и уникальность не имеют значения, используйте коллекцию. Если вы отправляете упорядоченный набор элементов, используйте список. Если вы передаете данные таким образом, чтобы каждый элемент был уникальным, но порядок не имеет значения, используйте набор. Используйте тип, который имеет смысловое значение, подходящее для обмена. В некоторых случаях, когда семантика и методы, которые вам нужны, не обязательно выравниваются (предположим, что вам нужен AddRange), создайте исключение или используйте методы преобразования.