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

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

public static IEnumerable Shuffle(this IEnumerable 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 DistinctBy(this IEnumerable source, 
                                              Func keySelector)
{
    HashSet seenKeys = new HashSet(); //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 по крайней мере.

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

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