Почему это считают плохим для представления Списка <T>? [дубликат]
Я предполагаю, что у вас есть изображение в Project Setting->Build Phases->Copy Bundle Resources, которое теряет свою ссылку и появляется в красном цвете текста. Удалите это изображение и снова добавьте.
Это часто происходит из-за переноса файла изображения после добавления в проект, где изображение было добавлено как ссылка вместо копии.
May это может решить вашу проблему.
6 ответов
Я соглашаюсь с moose-in-the-jungle здесь: List<T> неограниченный, чрезмерно увеличенный в размерах объект, который имеет много "багажа" в нем.
, К счастью, решение просто: представьте IList<T> вместо этого.
Это представляет базовый интерфейс, который имеет большинство все из List<T> методы (за исключением вещей как AddRange()), и это не ограничивает Вас к определенному List<T> тип, который позволяет Вашим потребителям API использовать своих собственных лиц, осуществляющих внедрение IList<T> лет.
еще для большей гибкости, рассмотрите представление некоторых наборов к IEnumerable<T>, в надлежащих случаях.
Существует эти 2 главных причины:
- List< T> довольно чрезмерно увеличенный в размерах тип со многими участниками, не релевантными во многих сценариях (также “busy” для общедоступных объектных моделей).
- класс распечатывается, но не специально предназначенный, чтобы быть расширенным (Вы не можете переопределить участников)
Это только рассмотрело плохую практику, если Вы пишете API, который будет использоваться тысячами или миллионами разработчиков.
руководство по проектированию платформы.NET предназначено для общедоступных API Microsoft.
, Если у Вас есть API, это не используется большим количеством людей, необходимо проигнорировать предупреждение.
Одна из причины - то, что пользователь будет в состоянии изменить список, и владелец списка не будет знать об этом, в то время как в некоторых случаях это должно сделать некоторый материал после добавляющих/удаляющих объектов к/от списку. Даже если это не требуется теперь, что это может стать требованием в будущем. Таким образом, лучше добавить AddXXX / метод RemoveXXX владельцу класса и представить список IEnumerable или (который лучше, по-моему), представляют его как IList и используют ObservableCollection от WindowsBase.
я думаю, что Вы не хотите своих потребителей, добавляющих новые элементы в Ваш возврат. API должен быть ясен и завершен и если он возвращает массив, он должен возвратить точную структуру данных. Я не думаю, что это имеет какое-либо отношение к T на, говорят, а скорее возврат List<> вместо массива [] непосредственно
Одна причина состоит в том, потому что Список не что-то, что можно моделировать. Даже в менее - популярные библиотеки, я видел повторения, которые раньше представляли Объект списка как должное IList к этой рекомендации, и в более поздних версиях, решенных, чтобы не хранить данные в списке вообще (возможно, в базе данных). Поскольку это был IList, это не было повреждающееся изменение, чтобы изменить реализацию под клиентами и все же сохранить всех работой.