Почему Queue (T) и Stack (T) не реализуют ICollection (T)?

Прежде чем я даже спрошу, позвольте мне получить очевидный ответ: интерфейс ICollection<T> включает в себя метод Remove для удаления произвольного элемента, который Queue<T> и Stack<T> не могут реально поддерживать ( поскольку они могут удалять только "конечные" элементы).

Хорошо, я это понимаю. На самом деле, мой вопрос касается не только типов коллекций Queue<T> или Stack<T>; скорее, о конструктивном решении не внедрять ICollection<T> для любого родового типа, который по существу представляет собой набор значений T.

Здесь я нахожу странным. Скажем, у меня есть метод, который принимает произвольный набор T, и для кода, который я пишу, было бы полезно узнать размер коллекции. Например (приведенный ниже код является тривиальным, только для иллюстрации!):

// Argument validation omitted for brevity.
static IEnumerable<T> FirstHalf<T>(this ICollection<T> source)
{
    int i = 0;
    foreach (T item in source)
    {
        yield return item;
        if ((++i) >= (source.Count / 2))
        {
            break;
        }
    }
}

Теперь нет причин, по которым этот код не мог работать с Queue<T> или Stack<T>, за исключением того, что эти типы не реализуют ICollection<T>. Конечно, они реализуют ICollection - я предполагаю, что главным образом для свойства Count, но это приводит к странному методу оптимизации, подобному этому:

// OK, so to accommodate those bastard Queue<T> and Stack<T> types,
// we will just accept any IEnumerable<T>...
static IEnumerable<T> FirstHalf<T>(this IEnumerable<T> source)
{
    int count = CountQuickly<T>(source);
    /* ... */
}

// Then, assuming we've got a collection type with a Count property,
// we'll use that...
static int CountQuickly<T>(IEnumerable collection)
{
    // Note: I realize this is basically what Enumerable.Count already does
    // (minus the exception); I am just including it for clarity.
    var genericColl = collection as ICollection<T>;
    if (genericColl != null)
    {
        return genericColl.Count;
    }

    var nonGenericColl = collection as ICollection;
    if (nonGenericColl != null)
    {
        return nonGenericColl.Count;
    }

    // ...or else we'll just throw an exception, since this collection
    // can't be counted quickly.
    throw new ArgumentException("Cannot count this collection quickly!");
}

Разве не имеет смысла просто полностью отказаться от интерфейса ICollection (я не имею в виду отказаться от реализации, конечно, поскольку это было бы нарушением изменения, я имею в виду, прекратить использовать его) и просто реализовать ICollection<T> с явной реализацией для членов, которые не имеют идеального соответствия?

Я имею в виду, посмотрите, что предлагает ICollection<T>:

• Count - Queue<T> и Stack<T> оба имеют это.
• IsReadOnly - Queue<T> и Stack<T> легко могли иметь это.
• Add - Queue<T> может реализовать это явно (с помощью Enqueue), как и Stack<T> (с Push).
• Clear - Проверьте.
• Contains - Проверьте.
• CopyTo - Проверьте.
• GetEnumerator - Проверить (duh).
• Remove - Это единственное, что Queue<T> и Stack<T> не имеют идеального соответствия.

И вот настоящий кикер: ICollection<T>.Remove возвращает a bool; поэтому явная реализация для Queue<T> может полностью (например) проверить, является ли элемент, который нужно удалить, фактически элементом head (с использованием Peek), и если да, вызовите Dequeue и верните true, в противном случае верните false. Stack<T> может быть легко предоставлена ​​аналогичная реализация с Peek и Pop.

Хорошо, теперь, когда я написал около тысячи слов о том, почему я думаю, что это было бы возможно, я задаю очевидный вопрос: почему разработчики Queue<T> и Stack<T> не реализовали это интерфейс? То есть, каковы были конструктивные факторы (которые я, вероятно, не рассматриваю), которые привели к решению, что это будет неправильный выбор? Почему вместо этого был реализован ICollection?

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

В принципе, я чувствую, что должна быть довольно веская причина. Queue<T> (например) не реализует ICollection<T>, и я не хочу просто идти слепо вперед, разрабатывая свои собственные типы и реализуя интерфейсы в неуместным образом, не будучи информированным и полностью не понимая, что я делаю.

Я извиняюсь за сверхдолговечный вопрос.

Ответы

public void SomeMethod<T>( ICollection<T> collection, T valueA, T valueB)
{

  collection.Add( valueA);
  collection.Add( valueB);

  if( someComplicatedCondition())
  {
    collection.Remove(valueA);
  }
}