кусок кода, который вызывается только один раз, заслуживает собственного метода?

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

• Это помогает сделать ваш код самодокументируемым.
• Это упрощает (модульное) тестирование.
• Это помогает остановить вас от методов длиной в сотни строк.
• Возможно, вы захотите использовать этот код в другом месте в будущем.

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

Три причины начать с:

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

Конечно, с этим можно переусердствовать, но это определенно может быть полезно.

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

Мы надеемся, что это облегчает более чистый код, и его должно быть легче тестировать.

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

См. обоснования, приведенные для рефакторинга Compose Method.

Удобочитаемость — моя главная причина такого поведения при кодировании.

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

Почему мы пишем книги абзацами и главами? Почему в песнях есть строфы/куплеты, припевы и переходы? Потому что легче воспринимать большую идею небольшими, очень конкретными кусками.

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

По крайней мере, это моя интерпретация.

Виртуальные машины Java обычно имеют ограничение на максимальный размер метода, который можно встроить. Извлечение редко вызываемого кода может, так сказать, смазать колеса. Можете указать примеры?