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

Question

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

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

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

За исключением целей документацииКакие другие причины могут оправдать помещение только 4 строк кода (которые вызываются только один раз!) в собственный метод?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

Читаемость - моя главная причина такого поведения при кодировании.

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

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

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

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

Answer 7

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