Свойство Count vs метод Count ()?
работа с коллекцией у меня есть два способа получения количества объектов; Count (свойство) и Count() метод. Кто-нибудь знает какие ключевые различия? Возможно, я ошибаюсь, но я всегда использую свойство Count в любых условных операторах, потому что я предполагаю, что метод Count() выполняет какой-то запрос к коллекции, где as Count должен быть уже назначен до меня 'получение."Но это предположение - я не знаю, повлияет ли производительность, если я неправильный.
EDIT: из любопытства тогда, Count () бросит исключение, если коллекция равна нулю? Потому что я уверен, что свойство Count просто возвращает 0.
8 ответов:
Декомпиляция источника для
Count()
метод расширения показывает, что он проверяет, является ли объектICollection
(общая или иначе) и если так просто возвращает базовыйCount
свойства:Итак, если ваш код обращается
Count
вместоCount()
, вы можете обойти проверку типа-теоретическое преимущество производительности, но я сомневаюсь, что это будет заметно!// System.Linq.Enumerable public static int Count<TSource>(this IEnumerable<TSource> source) { checked { if (source == null) { throw Error.ArgumentNull("source"); } ICollection<TSource> collection = source as ICollection<TSource>; if (collection != null) { return collection.Count; } ICollection collection2 = source as ICollection; if (collection2 != null) { return collection2.Count; } int num = 0; using (IEnumerator<TSource> enumerator = source.GetEnumerator()) { while (enumerator.MoveNext()) { num++; } } return num; } }
представление только одна причина выбрать одно или другое. Выбирающий.Count () означает, что ваш код будет более общим. У меня были случаи, когда я рефакторировал некоторый код, который больше не создавал коллекцию, а вместо этого что-то более общее, например IEnumerable, но в результате другой код сломался, потому что он зависел от
.Count
и мне пришлось изменить его на.Count()
. Если бы я сделал точку, чтобы использовать.Count()
везде, код, вероятно, будет более многоразовым и ремонтопригодным. Обычно предпочитают используйте более общие интерфейсы, если вы можете уйти с ним, это ваш лучший выбор. Под более общим я подразумеваю более простой интерфейс, который реализуется большим количеством типов, и, таким образом, вы получаете большую совместимость между кодом.Я не говорю
.Count()
лучше, я просто говорю, что есть другие соображения, которые больше касаются возможности повторного использования кода, который вы пишете.
The
.Count()
метод может быть достаточно умным, или знать о типе в вопросе, и если да, то это может использовать базовый.Count
собственность.опять же, это не может быть.
Я бы сказал, что можно с уверенностью предположить, что если коллекция имеет собственность, это будет ваш лучший выбор, когда дело доходит до производительности.
если
.Count()
метод не знает о коллекции, он будет перечислять над ней, что будет операция O(n).
метод Count () - это метод расширения, который повторяет каждый элемент IEnumerable и возвращает количество элементов. Если экземпляр IEnumerable на самом деле является List, поэтому он оптимизирован для возврата свойства Count вместо итерации всех элементов.
Если есть свойство Count или Length, вы всегда должны предпочесть его методу Count (), который обычно повторяет всю коллекцию для подсчета количества элементов внутри. (Исключения были бы, когда метод Count() против источника Linq to SQL или Linq to Entities, например, в этом случае он выполнял бы запрос count против источника данных. Даже тогда, если есть свойство Count, вы хотели бы предпочесть это, так как у него, вероятно, меньше работы.)
метод Count () - это метод LINQ, который работает с любым IEnumerable. Вы ожидаете, что метод Count () будет перебирать всю коллекцию, чтобы найти счетчик, но я считаю, что код LINQ на самом деле имеет некоторые оптимизации, чтобы определить, существует ли свойство Count, и если да, то используйте это.
Так что они оба должны делать почти одинаковые вещи. Свойство Count, вероятно, немного лучше, поскольку там не нужно проверять тип.
короткая версия: Если у вас есть выбор между
Count
собственность иCount()
метод всегда выбирает свойство.разница главным образом вокруг эффективности деятельности. Все коллекции BCL, которые выставляют a
Count
свойство сделать это в O (1) моды. ЭлементCount()
метод, хотя может и часто будет стоить O (N). Есть некоторые проверки, чтобы попытаться получить его в O (1) для некоторых реализаций, но это ни в коем случае не гарантировано.
Count()
есть ли метод расширения от LINQ -Count
является собственность наList
s, фактические объекты коллекции .NET.в таком виде
Count()
почти всегда будет медленнее, так как он будет перечислять коллекции объектов / запросов. В списке, очереди, стеке и т. д. ИспользуйтеCount
. Или для массива -Length
.