Список <T>или IList <T>

Question

Может кто-нибудь объяснить мне, почему я хотел бы использовать IList поверх List в C #?

Смежный вопрос: Почему разоблачение считается плохим List<T>

Answer 1

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

Answer 2

Что, если .NET 5.0 заменит System.Collections.Generic.List<T> на System.Collection.Generics.LinearList<T>. .NET всегда принадлежит имя List<T>, но они гарантируют, что IList<T> является контрактом. Так что ИМХО, мы (по крайней мере, я) не должны использовать чье-то имя (хотя в данном случае это .NET), и позже возникнут проблемы.

В случае использования IList<T>, вызывающая сторона всегда гарантирует работу вещей, и разработчик может изменить базовую коллекцию на любую альтернативную конкретную реализацию IList

Answer 3

Все концепции в основном изложены в большинстве ответов выше относительно того, зачем использовать интерфейс над конкретными реализациями.

IList<T> defines those methods (not including extension methods)

IList<T> MSDN-ссылка

1. Добавить
2. Очистить
3. Содержит
4. CopyTo
5. GetEnumerator
6. IndexOf
7. Вставить
8. Удалить
9. RemoveAt

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

List<T> MSDN-ссылка

Answer 4

Вы бы, потому что определение IList или ICollection открыло бы другие реализации ваших интерфейсов.

Возможно, вы захотите иметь IOrderRepository, который определяет набор заказов в IList или ICollection. Тогда у вас могут быть различные виды реализаций для предоставления списка заказов, если они соответствуют «правилам», определенным вашим IList или ICollection.

Answer 5

IList <> почти всегда предпочтительнее в соответствии с рекомендациями другого автора, однако учтите, есть ошибка в .NET 3.5 sp 1 при запуске IList <> через более одного цикла сериализации / десериализации с WCF DataContractSerializer.

Теперь есть SP, чтобы исправить эту ошибку: KB 971030

Answer 6

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

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

Answer 7

Вы можете взглянуть на этот аргумент с нескольких точек зрения, в том числе с точки зрения чисто ОО-подхода, в котором говорится, что программирование против интерфейса не является реализацией. С этой мыслью использование IList следует тому же принципу, что и обход и использование интерфейсов, которые вы определяете с нуля. Я также верю в факторы масштабируемости и гибкости, предоставляемые интерфейсом в целом. Если класс, реализующий IList , необходимо расширить или изменить, код потребления не должен изменяться; он знает, чего придерживается контракт IList Interface. Однако использование конкретной реализации и List для изменяющегося класса может также привести к необходимости изменения вызывающего кода. Это связано с тем, что класс, придерживающийся IList , гарантирует определенное поведение, которое не гарантируется конкретным типом, использующим List .

Также имея возможность делать что-то вроде изменения стандартной реализации List в классе реализующий IList , например, .Add, .Remove или любой другой метод IList дает разработчику lot гибкости и мощи, иначе предопределено List

Answer 8

Как правило, хорошим подходом является использование IList в вашем общедоступном API (когда это необходимо, и семантика списка), а затем внутренний список для реализации API. Это позволяет вам перейти на другую реализацию IList, не нарушая код, который использует ваш класс.

Имя класса List может быть изменено в следующей платформе .net, но интерфейс никогда не изменится, так как интерфейс является контрактом.

Обратите внимание, что если ваш API будет использоваться только в циклах foreach и т. Д., Вы можете вместо этого рассмотреть возможность использования IEnumerable.