Может ли цепочка методов C# быть слишком длинной?

Технических ограничений на длину цепочки методов нет.

Тем не менее, три области, которые могут стать проблематичными, — это отладка, обработка исключений и удаление ресурсов.

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

Обработка исключений усложняется тем фактом, что вы не можете изолировать исключения, вызванные одним методом, по сравнению с другим. Обычно это не проблема, если вы не можете сделать что-то значимое в ответ на исключение — просто позвольте ему распространяться по цепочке вызовов. Однако, если вы позже поймете, что вам нужна обработка исключений, вам придется реорганизовать синтаксис цепочки, чтобы иметь возможность вставлять соответствующие обработчики try/catch.

Аналогично обработке исключений случай детерминированного удаления ресурсов. Проще всего в C# сделать это с помощью using() - к сожалению, синтаксис цепочки исключает это. Если вы вызываете методы, которые возвращают одноразовые объекты, вероятно, лучше избегать синтаксиса цепочки, чтобы вы могли быть хорошим «гражданином кода» и избавляться от этих ресурсов как можно раньше.

Синтаксис цепочек методов часто используется в флуктуальных API, где он позволяет более эффективно использовать синтаксис вашего кода. точно отражать последовательность операций, которые вы намереваетесь. LINQ — это один из примеров в .NET, где часто встречается свободный синтаксис.

Удобочитаемость является самой большой проблемой, но часто это вообще не проблема.

Вы также можете описать синтаксис запроса LINQ как (под всем этим) точно такую ​​настройку. Это просто делает его красивее ;-p

Одна возможная проблема заключается в том, что вам нужно ввести такие вещи, как using или lock; с плавным API у вас может возникнуть соблазн просто удалить эти компоненты, но это может привести к странностям, когда выдается исключение.

Другая возможная мысль заключается в том, что вам может понадобиться более детальная обработка исключений для некоторых вызовов; но вы всегда можете просто прервать поток:

var foo = bar.MethodA().MethodB(...).MethodC();
try {
    foo.MethodD();
} catch (SomeSpecificException) {
    //something interesting
}

Или вы могли бы даже сделать это в методе расширения, чтобы сохранить плавный внешний вид:

bar.MethodA().MethodB(...).MethodC().MyExtensionMethodD();

где MyExtensionMethodD — это тот, который вы добавляете со специальной обработкой (исключения, блокировки, использование и т. д.).

Некоторые считают это запахом кода, а другие нет. Каждый раз, когда вы видите следующее:

Foo.getBar().getBlah().getItem().getName();

Вы действительно должны думать: «Чего я действительно хочу?» Вместо этого, возможно, ваш метод должен содержать вызов функции:

String getName(Int _id, String _item)
{
    return myBar.getName( _id, _item );
}

который затем делегирует вниз, среди классов. Затем, если что-то изменится в одном из ваших классов при более позднем обновлении, вы точно увидите, где это произошло, и сможете изменить это в одном месте.

Единственная проблема, которую вы должны учитывать в связи с этим (если вы игнорируете удобочитаемость), - это обработка ресурсов и GC. Вопросы, которые вы должны задать, следующие.

• Являются ли вызовы, которые я делаю, возвращающими объектами, от которых следует избавляться?
• Я инициирую много вещей внутри одной области, а не в меньших областях, на которые GC может быть более реактивным? (GC планируется запускать каждый раз, когда вы покидаете область действия, хотя планирование и время его фактического запуска — это две разные вещи :-p).

Но на самом деле... независимо от того, вызываете ли вы один метод в строке или связываете их все вместе, в IL все оказывается одинаковым (или почти таким же).

Джош

В дополнение к другим ответам, есть техническое ограничение, с которым вы можете столкнуться: очень длинные цепочки методов приведут к сбою служб, предоставляющих IntelliSense, а затем и их хост-процессов (Linqpad 6, Visual Studio 2019 и, возможно, другие).

Я обнаружил это, когда преобразовал сценарий, который я использую для отслеживания своей личной работы, из API на основе коллекции в цепочку вызовов Fluent API. Я обнаружил, что код, который у меня был, приведет к сбою в любой среде IDE, в которую я его вставлю. Исследования привели меня к этой давней проблеме с github: https://github.com/dotnet/roslyn/issues/9795

Достаточно просто разбить очень длинные цепочки на отдельные операторы.