Является ли обычной (или поощряемой) практикой перегружать функцию для принятия IEnumerable <T>, ICollection <T>, IList <T> и т. Д.?

Question

EDIT:

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

---

Предположим, у меня есть три перегруженные функции, один принимая IEnumerable<T>, один принимая ICollection<T> и один принимая IList<T>, что-то вроде следующего:

public static T GetMiddle<T>(IEnumerable<T> values) { 
    IList<T> list = values as IList<T>; 
    if (list != null) return GetMiddle(list); 

    int count = GetCount<T>(values); 

    T middle = default(T); 
    int index = 0; 

    foreach (T value in values) { 
     if (index++ >= count/2) { 
      middle = value; 
      break; 
     } 
    } 

    return middle; 
} 

private static T GetMiddle<T>(IList<T> values) { 
    int middleIndex = values.Count/2; 
    return values[middleIndex]; 
} 

private static int GetCount<T>(IEnumerable<T> values) { 
    // if values is actually an ICollection<T> (e.g., List<T>), 
    // we can get the count quite cheaply 
    ICollection<T> genericCollection = values as ICollection<T>; 
    if (genericCollection != null) return genericCollection.Count; 

    // same for ICollection (e.g., Queue<T>, Stack<T>) 
    ICollection collection = values as ICollection; 
    if (collection != null) return collection.Count; 

    // otherwise, we've got to count values ourselves 
    int count = 0; 
    foreach (T value in values) count++; 

    return count; 
} 

Идея заключается в том, что, если я у меня есть IList<T>, что облегчает мою работу; с другой стороны, я все еще могу работать с ICollection<T> или даже с IEnumerable<T>; реализация этих интерфейсов не так эффективна.

Я не был уверен, что это даже сработает (если среда выполнения сможет выбрать перегрузку на основе переданного параметра), но я протестировал ее и, похоже, это.

Мой вопрос: есть ли проблема с этим подходом, о котором я не думал? В качестве альтернативы, это на самом деле хороший подход, но есть лучший способ его достижения (возможно, попытавшись отбросить аргумент values до IList<T> и запустить более эффективную перегрузку, если бросок работает)? Мне просто интересно узнать мысли других.

Answer 1

Если вы посмотрите, как методы расширения LINQ реализованы с использованием Reflector, вы можете увидеть, что несколько методов расширения на IEnumerable < T>, например Count(), пытаются передать последовательность ICollection < T> или IList < T> для оптимизации работы (например, с помощью ICollection < T>.Count, а не итерирование через IEnumerable < T> и подсчет элементов). Таким образом, ваш лучший выбор, скорее всего, примет IEnumerable < T>, а затем сделайте такие оптимизации, если доступны ICollection < T> или IList < T>.

Answer 2

Обычно при проектировании интерфейсов вы хотите принять тип «наименьшего общего знаменателя» для аргументов. Для типов возврата это вопрос некоторых дебатов. Я вообще думаю, что создание вышеуказанных перегрузок является излишним. Это самая большая проблема - это введение ненужных кодовых путей, которые теперь должны быть протестированы. Лучше иметь один метод, который выполняет операцию в одну сторону и работает в 100% случаев. С приведенными выше перегрузками вы можете иметь непоследовательность в поведении и даже не осознавать этого, или, что еще хуже, вы можете случайно ввести изменение в одном, а не в других экземплярах.

Если вы можете сделать это с помощью IEnumerable<T>, тогда используйте это, если нет, то используйте наименее необходимый интерфейс.

Answer 3

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

Вы можете принять параметр IEnumerable < T> и внутренне проверить, действительно ли это ICollection < T> или IList < T>, и оптимизировать соответственно.

Это может быть аналогичным некоторым оптимизации в некоторых методах расширения IEnumerable < T> в .NET 3.5 Framework.

Answer 4

Я думаю, что одна из версий, принимающая IEnumerable <T>, была бы способ пойти и проверить внутри метода, если этот параметр является одним из более производных типов коллекций. С трех версиях, как вы предлагаете, вы теряете преимущество эффективности, если кто-то проходит вам (выполнения) IList <T>, что компилятор статически рассматривает IEnumerable <T>:

 IList<string> stringList = new List<string> { "A", "B", "C" }; 
     IEnumerable<string> seq = stringList; 
     Extensions.GetMiddle(stringList); // calls IList version 
     Extensions.GetMiddle(seq);  // calls IEnumerable version 

Answer 5

Нет. Это, конечно, редкость.

В любом случае. С IList <T> наследует от ICollection <T> и IEnumerable <T> и ICollection <T> наследуется от IEnumerable <T>, ваша единственная проблема будет производительность типов IEnumerable <T>.

Я просто не вижу причин, чтобы перегрузить функцию таким образом, обеспечивая различные сигнатуры для достижения точно такой же результат и принимать те же типы в качестве параметров (не важно, если у вас есть IEnumerable <T> или IList <T> , вы сможете передать его любой из трех перегрузок); это просто вызовет путаницу.

Когда вы перегружаете функцию, это просто способ передать другой тип параметра, который вы не можете передать функции, если у него не будет такой подписи.

Не оптимизируйте, если это действительно необходимо. Если вы хотите оптимизировать, сделайте это под прикрытием. Вы не будете притворяться, что кто-то использует ваш класс, чтобы быть в курсе этой «оптимизации», чтобы решить, какую подпись метода использовать, не так ли?

Answer 6

Я действительно безразличен. Если бы я это видел, я бы не подумал об этом. Но идея Джо имеет заслугу. Это может выглядеть следующим образом.

public static T GetMiddle<T>(IEnumerable<T> values) 
{ 
    if (values is IList<T>) return GetMiddle((IList<T>)values); 
    if (values is ICollection<T>) return GetMiddle((ICollection<T>)values); 

    // Use the default implementation here. 
} 

private static T GetMiddle<T>(ICollection<T> values) 
{ 
} 

private static T GetMiddle<T>(IList<T> values) 
{ 
} 

Answer 7

В то время как он является законным перегрузить метод, чтобы принять либо базовый тип или производный тип, при этом все другие параметры, будучи в остальном идентичны, это только выгодно делать это, если компилятор часто будет в состоянии идентифицировать последняя форма как лучшее совпадение. Поскольку для объектов, которые реализуют ICollection<T>, будет распространяться код, которому требуется только IEnumerable<T>, было бы очень важно, чтобы реализация ICollection<T> была передана в перегрузку IEnumerable<T>. Следовательно, перегрузка IEnumerable<T> должна, вероятно, проверять, реализует ли передаваемый объект ICollection<T> и обрабатывает, если это так.

Если самый естественный способ реализации логики для ICollection<T> было бы написать специальный метод для этого, не было бы ничего особенно плохого в общественную перегрузку, которая принимает в ICollection<T>, и имея перегрузку IEnumerable<T> называют ICollection<T> один, если задан объект, который реализует ICollection<T>. Наличие такой перегрузки должно быть общедоступным, но это не повредит.С другой стороны, в тех случаях, когда объект реализует как IEnumerable<T> и ICollection, но не ICollection<T> (например, List<Cat> реализует IEnumerable<Animal> и ICollection, но не ICollection<Animal>), один, возможно, захотите использовать оба интерфейса, но это не может быть сделано без либо typecasting в методе, который их использует, либо передавая метод, который использует их как ссылку ICollection, так и ссылку IEnumerable<T>. Последний был бы очень уродливым в публичном методе, и прежний подход потерял бы преимущества перегрузки.