Есть несколько подобных вопросов, которые касаются правильных типов ввода и вывода.нравится, Мой вопрос больше касается правильной практики, именования методов, выбора типа параметра, защиты от несчастных случаев и т. Д.вслед заLinq.

Linq почти везде имеет дело сIEnumerable и это только не это, но это также вводит что-то чуждоенас называетсяотложенное исполнение. Теперь мы могли ошибаться при разработке наших методов (особенно методов расширения), когда думали, что лучшая идея - выбрать самый простой тип. Итак, наши методы выглядят так:

public static IEnumerable<T> Shuffle<T>(this IEnumerable<T> lstObject)
{
    foreach (T t in lstObject)
       //some fisher-yates may be
}

Опасность, очевидно, заключается в том, что когда мы смешиваем вышеупомянутую функцию сLinq и этотакой восприимчивый

var query = foos.Select(p => p).Where(p => p).OrderBy(p => p); //doesn't execute
//but
var query = foos.Select(p => p).Where(p => p).Shuffle().OrderBy(p => p);
//the second line executes up to a point.

Большое редактирование здесь:

Чтобы прояснить вышеприведенную строку - мой вопрос не о том, что второе выражение не оценивается, серьезно нет. Программисты это знают. Мое беспокойство оShuffle метод фактически выполняет запрос до этого момента. Смотрите первый запрос, где ничего не выполняется. Теперь аналогичным образом при создании другого выражения Linq (которое должно быть выполнено позже) наша пользовательская функция воспроизводит спойлспорт. Другими словами, как сообщить звонящемуShuffle это не та функция, которую они хотели бы получить в этот момент выражения Linq. Я надеюсь, что дело дошло до дома. Извиняюсь! :) Хотя это так же просто, как проверить и изучить метод, я спрашиваю, как вы, ребята, обычно программируете в обороне ...

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

Но такая функция работает с волшебствомLinq:

public static IEnumerable<S> DistinctBy<S, T>(this IEnumerable<S> source, 
                                              Func<S, T> keySelector)
{
    HashSet<T> seenKeys = new HashSet<T>(); //credits Jon Skeet
    foreach (var element in source)
        if (seenKeys.Add(keySelector(element)))
            yield return element;
}

Как вы можете видеть, обе функции принимаютIEnumerable<>, но вызывающая сторона не знает, как реагируют функции. Каковы общие меры предосторожности, которые вы, ребята, принимаете здесь?

Назовите наши пользовательские методы соответствующим образом, чтобы он дал понять вызывающей стороне, что он сулит ничего хорошего или нетLinq?

Переехатьленивый методы в другое пространство имен, и сохранитьLinq- по-другому, чтобы это хотя бы дало какую-то идею?

Не принимайтеIEnumerable в качестве параметра дляimmediately выполнение методов, но вместо этого взять более производный тип или сам конкретный тип, который, таким образом, оставляетIEnumerable только для ленивых методов? Это возлагает на вызывающего абонента бремя выполнения возможных невыполненных выражений? Это вполне возможно для нас, так как снаружиLinq мир, с которым мы едва имеем делоIEnumerableс, и большинство базовых классов коллекции реализуют доICollection по крайней мере.

Или что-нибудь еще? Мне особенно нравится 3-й вариант, и это то, с чем я собирался, но подумал, чтобы получить ваши идеи до. Я видел много кода (хороший маленькийLinq как методы расширения!) даже от хороших программистов, которые принимаютIEnumerable и сделатьToList() или что-то похожее на них внутри метода. Я не знаю, как они справляются с побочными эффектами ..

Редактировать: После понижения и ответа я хотел бы уточнить, что речь идет не о программистах, не знающих о том, как работает Linq (наш уровень может быть на каком-то уровне, но это совсем другое), а о том, что многие функции были написаны, не принимая Linq в аккаунт тогда. Теперь связывание сразу выполняющегося метода с методами расширения Linq делает его опасным. Итак, мой вопрос: есть ли общие правила, которым следуют программисты, чтобы сообщить вызывающей стороне, что использовать со стороны Linq, а что нет?Это больше о программировании в обороне, чем если вы не знаете, как использовать то, тогда мы не можем помочь! (или, по крайней мере, я верю) ..