Почему считается бесполезным показывать List <T>?

Ответ 1

Я согласен с лосями в джунглях здесь: List<T> - это безусловный, раздутый объект, в котором есть много "багажа".

К счастью, решение прост: вместо этого выведите IList<T>.

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

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

Ответ 2

Есть две основные причины:

• Список < Т > является довольно раздутым типом со многими членами, не имеющими значения во многих сценариях (слишком "занят" для моделей общедоступных объектов).
• Класс непечатан, но специально не предназначен для расширения (вы не можете переопределить какие-либо элементы)

Ответ 3

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

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

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

Ответ 4

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

Ответ 5

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

Ответ 6

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