List.AddRange()
существует, но IList.AddRange()
не существует.
Это кажется мне странным. В чем причина этого?
List.AddRange()
существует, но IList.AddRange()
не существует.
Это кажется мне странным. В чем причина этого?
Ответы:
Потому что интерфейс должен быть простым в реализации и не содержать «все, кроме кухни». Если вы добавляете, AddRange
вы должны добавить InsertRange
и RemoveRange
(для симметрии). Лучше спросить, почему нет методов расширения для IList<T>
интерфейса, аналогичного IEnumerable<T>
интерфейсу. (методы расширения для на месте Sort
, BinarySearch
... было бы полезно)
IFoo
) указать «вспомогательное» пространство имен (например MyAssembly
), так что если класс заявляет о реализации, IFoo
но не имеет метода int Bar(String)
, компилятор автоматически генерировать метод int IFoo.Bar(String p1) {return MyAssembly.ClassHelpers.IFoo.Bar(this, p1);}
Если бы такая функция существовала, интерфейсы могли бы включать больше методов, например, AddRange
которые могли бы быть реализованы в терминах базового поведения, но которые некоторые реализации могли бы оптимизировать.
Для тех, кто хочет иметь методы расширения для "AddRange", "Sort", ... в IList,
Ниже приведен AddRange
метод расширения:
public static void AddRange<T>(this IList<T> source, IEnumerable<T> newList)
{
if (source == null)
{
throw new ArgumentNullException(nameof(source));
}
if (newList == null)
{
throw new ArgumentNullException(nameof(newList));
}
if (source is List<T> concreteList)
{
concreteList.AddRange(newList);
return;
}
foreach (var element in newList)
{
source.Add(element);
}
}
Я создал небольшую библиотеку, которая этим занимается. Я считаю это более практичным, чем переделывать методы расширения в каждом проекте.
Некоторые методы медленнее, чем List, но они делают свою работу.
Вот GitHub, чтобы их заинтересовать:
AddRange/RemoveRange/InsertRange
может работать непосредственно с «внутренней» коллекцией и оптимизироватьCapacity
управление и использовать такие методы, какArray.Copy
перемещение блоков данных. Метод расширенияRemoveRange
, вероятно, будет на порядок медленнее, чемList.RemoveRange