Почему IReadOnlyCollection имеет ElementAt, но не IndexOf

IReadOnlyList<T> has no IndexOf() for no good reason whatsoever.

Если вы действительно хотите найти повод для упоминания, то причина историческая:

Еще в середине девяностых, когда был основан C #, люди еще не совсем осознавали преимущества неизменяемости и доступности для чтения, поэтому интерфейс IList<T>, который они встроили в язык, к сожалению, был изменчивым.

Правильнее было бы придумать IReadOnlyList<T> в качестве базового интерфейса и заставить IList<T> его расширять, добавляя только методы мутации, но этого не произошло.

IReadOnlyList<T> был изобретен значительно позже IList<T>, и к тому времени было уже слишком поздно переопределять IList<T> и расширять его IReadOnlyList<T>. Итак, IReadOnlyList<T> был построен с нуля.

Они не могли заставить IReadOnlyList<T> расширить IList<T>, потому что тогда он унаследовал бы методы мутации, поэтому вместо этого они основали его на IReadOnlyCollection<T> и IEnumerable<T>. Они добавили индексатор this[i], но затем либо забыли добавить другие методы, такие как IndexOf(), либо намеренно опустили их, поскольку они могут быть реализованы как методы расширения, что упростило интерфейс. Но они не предоставили никаких таких методов расширения.

Итак, вот метод расширения, который добавляет IndexOf() к IReadOnlyList<T>:

using Collections = System.Collections.Generic;

    public static int IndexOf<T>( this Collections.IReadOnlyList<T> self, T elementToFind )
    {
        int i = 0;
        foreach( T element in self )
        {
            if( Equals( element, elementToFind ) )
                return i;
            i++;
        }
        return -1;
    }

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

Это потому, что IReadOnlyCollection (который реализует IEnumerable) не обязательно реализует indexing, что часто требуется, когда вы хотите численно упорядочить List. IndexOf из IList.

Подумайте о коллекции без индекса, например о Dictionary, в Dictionary нет понятия числового индекса. В Dictionary порядок не гарантируется, только отношение один к одному между ключом и значением. Таким образом, коллекция не обязательно подразумевает числовую индексацию.

Другая причина в том, что IEnumerable на самом деле не двухсторонний трафик. Подумайте об этом так: IEnumerable может перечислять элементы x раз, как вы указываете, и находить элемент в x (то есть ElementAt), но он не может точно знать, находится ли какой-либо из его элементов в каком индексе (то есть IndexOf) .

Но да, это все равно довольно странно, даже если вы так думаете, поскольку ожидаете, что у него будет либо одновременно ElementAt и IndexOf , либо ничего.

IndexOf - это метод, определенный в List, тогда как IReadOnlyCollection наследует только IEnumerable.

Это потому, что IEnumerable предназначен только для итерации сущностей. Однако индекс не применяется к этой концепции, потому что порядок произвольный и не гарантируется идентичность между вызовами IEnumerable. Кроме того, интерфейс просто заявляет, что вы можете перебирать коллекцию, тогда как List заявляет, что вы также можете выполнять добавление и удаление.

Метод ElementAt делает именно это. Однако я не буду использовать его, поскольку он повторяет все перечисление, чтобы найти один единственный элемент. Лучше использовать First или просто подход на основе списков.

В любом случае дизайн API кажется мне странным, поскольку он допускает (неэффективный) подход к получению элемента в n -ой позиции, но не позволяет получить индекс произвольного элемента, который был бы таким же неэффективным поиск до n итераций. Я согласен с Яном либо в обоих (что я бы не рекомендовал), либо ни в одном из них.

IReadOnlyCollection<T> имеет ElementAt<T>(), потому что это расширение IEnumerable<T>, в котором есть этот метод. ElementAt<T>() выполняет IEnumerable<T> заданное количество итераций и возвращает значение в качестве этой позиции.

IReadOnlyCollection<T> не хватает IndexOf<T>(), потому что, как IEnumerable<T>, он не имеет какого-либо определенного порядка, и поэтому концепция индекса не применяется. И IReadOnlyCollection<T> не добавляет никакой концепции порядка.

Я бы порекомендовал IReadOnlyList<T>, если вам нужна индексируемая версия IReadOnlyCollection<T>. Это позволяет правильно представить неизменяемую коллекцию объектов с индексом.

Это может быть кому-то полезно:

public static int IndexOf<T>(this IReadOnlyList<T> self, Func<T, bool> predicate)
{
    for (int i = 0; i < self.Count; i++)
    {
        if (predicate(self[i]))
            return i;
    }

    return -1;
}