Почему выставлять List <T> считается плохим? [Дубликат]

На этот вопрос уже есть ответ здесь:

Список <T> или IList <T> 18 ответов

Согласно FXCop, List не должен быть представлен в объектной модели API. Почему это считается плохой практикой?

Ответы на вопрос(6)

что пользователь сможет изменить список, а владелец списка об этом не узнает, хотя в некоторых случаях он должен что-то делать после добавления / удаления элементов в / из списка. Даже если это не требуется сейчас, оно может стать требованием в будущем. Поэтому лучше добавить метод AddXXX / RemoveXXX владельцу класса и предоставить список IEnumerable или (что лучше, на мой взгляд) представить его как IList и использовать ObservableCollection из WindowsBase.

 Joe24 мая 2013 г., 09:41
РазоблачениеList<T> какIList<T> или жеIEnumerable<T> не защищает от изменения пользователем списка (после приведения в случаеIEnumerable<T>). Если вы хотите вернуть неизменный список, вернитеReadOnlyCollection<T> или использоватьIEnumerable<T>.AsReadOnly(), который можно вернуть какIList<T>.
Решение Вопроса

List<T> это неограниченный, раздутый объект, в котором много «багажа».

К счастью, решение простое: разоблачитьIList<T> вместо.

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

Для большей гибкости рассмотрите возможность выставления некоторых коллекцийIEnumerable<T>когда уместно.

 perfectionist05 окт. 2017 г., 12:19
@MatthijsWessels согласился, что массив - большая проблема для IList - смотрите мой ответ здесьstackoverflow.com/a/36570307/1154384
 Jon Limjap30 дек. 2008 г., 14:33
kpollock - к сожалению SOAP веб-сервисыбудут превратить любой IList <T> в массив типа T [] -> сериализация не поддерживает тип общего списка.
 kpollock23 дек. 2008 г., 13:50
Что бы вы порекомендовали для веб-службы (где метод не может вернуть / взять интерфейс)?
 jlafay08 июн. 2011 г., 20:31
То, что вы используете IList <T>, не означает, что вы экономите память, если вы к этому стремитесь. Вы создаете его с помощью нового List <T> (), а переменная IList <T> по-прежнему указывает на List <T> в памяти. Кроме этого, я думаю, что обычно выгодно инкапсулировать коллекцию, а не подвергать ее прямому воздействию клиентского кода.
 Matthijs Wessels28 мар. 2014 г., 13:47
Будь осторожен сIList хоть.Array также реализуетIList и бросит исключение наAdd а такжеRemove, Это может сбивать с толку, так как многие люди этого не ожидают.
 Jon Limjap09 июн. 2011 г., 10:47
Конечно, @jlafay, но это не было целью ответа - дело просто в том, что есть другие реализации IList <T> или IEnumerable <T>, которыеМожно указывать на переменную, и я думаю, что в этом тоже смысл FxCop. С другой стороны, правила FxCop могут быть изменены, чтобы игнорировать это конкретное правило;)

что List - это не то, что вы можете имитировать. Даже в менее популярных библиотеках я видел итерации, которые раньше использовали объект List в качестве IList из-за этой рекомендации, и в более поздних версиях решили вообще не хранить данные в списке (возможно, в базе данных). Поскольку это был IList, это не было серьезным изменением, чтобы изменить реализацию под клиентами и, тем не менее, заставить всех работать.

List <T> - довольно раздутый тип со многими членами, не относящимися ко многим сценариям (слишком «занят» для публичных объектных моделей).Класс распечатан, но не предназначен специально для расширения (вы не можете переопределить ни одного члена)
 Ryan Lundy23 дек. 2008 г., 03:19
Абсолютно верно. Вот ссылка на Кшиштофа Квалина на эту тему:blogs.msdn.com/kcwalina/archive/2005/09/26/474010.aspx

что вы не хотите, чтобы ваши потребители добавляли новые элементы в вашу прибыль. API должен быть понятным и полным, и если он возвращает массив, он должен возвращать точную структуру данных. Я не думаю, что это имеет какое-либо отношение к T за слово, а скорее возвращает список <> вместо массива []

 TrueWill07 янв. 2012 г., 17:26
-1. Особенно,Свойства не должны возвращать массивы, В то время как методы могут, в общем случае, перечислимые последовательности и интерфейсы более идиоматичны для C #.

если вы пишете API, который будет использоваться тысячами или миллионами разработчиков.

Руководство по разработке .NET Framework предназначено для открытых API-интерфейсов Microsoft.

Если у вас есть API, который не используется многими людьми, вы должны игнорировать предупреждение.

 TrueWill07 янв. 2012 г., 17:42
Если в вашей ситуации руководство не имеет смысла, отключите его в проекте FxCop, но просмотритеруководящие принципы сначала внимательно
 TrueWill07 янв. 2012 г., 17:41
Хотя некоторые из правил FxCop являются руководящими принципами разработки структуры и могут не подходить для некоторых проектов, даже библиотеки, разработанные для небольших групп, могут выиграть от их выполнения. Вы когда-нибудь говорили 5 разработчикам, что им придется менять свои проекты, потому что вам нужно внести срочные изменения в библиотеку (скажем, чтобы наблюдать за изменениями, как упомянул @Kaagle)? Делали ли разработчики в вашей команде что-то, чего вы не ожидали, например, изменение содержимого свойства списка, которое вы хотели сделать доступным только для чтения?

Ваш ответ на вопрос