Когда мы должны создать новый метод?

Question

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

Существуют ли какие-либо шаблоны дизайна или книги, которые занимаются этим? Связанный вопрос был бы, если бы мы только устанавливали параметры в объекте, используя методы получения и установки. Очевидно, это создаст намного больше кода, но сделает вещи более управляемыми? Есть консенсус по этому поводу?

Answer 1

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

Это не всегда так, и рефракторинг не имеет смысла в рефракторинге, но часто помогает держать вещи в перспективе.

Answer 2

Метод должен делать одну вещь и делать это хорошо. Он не должен делать ничего более или менее того, что подразумевает его название. Метод CustomerSave также не должен нормализовать адрес клиента.

Метод должен касаться только одного «уровня» функциональности. Если в методе CustomerSave появляется более одной строки кода для каждого из следующих действий: открытие базы данных, регистрация изменений, проверка безопасности и т. Д., Тогда код работает на неправильном уровне, и необходимо создать новые методы для решения эти вещи в правильной детализации.

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

Код не должен быть повторяющимся. Дублирующая функциональность должна быть размещена в методе.

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

Answer 3

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

Answer 4

SLAP и DRY - хорошие принципы. Перейдите по этой ссылке http://tv.devexpress.com/SLAPrule.movie очень хорошая беседа мистера Джулиана. [Похоже, что видео-сайт некоторое время не работает. Пожалуйста, проверьте позже]

Answer 5

Вы вводите новые методы, даже если их вызывают только один раз, чтобы ограничить максимальную цикломатическую сложность

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

• Очевидный, DRY, он же DIE . Я следовал этой философии, пока она не приобрела крутые сокращения. Я не думаю, что когда-либо нужно, по любой причине, дублировать или копировать и вставлять код, независимо от того, насколько он короткий. Если вы это сделаете, вы завариваете кошмар.
• Для ограничения цикломатическая сложность . Гораздо лучше иметь 3 понятных метода, чем один запутанный метод. Это и другие правила применяются, даже если новый извлеченный метод вызывается только один раз
• Извлечение функциональных блоков для тестирования модулей
• Чтобы все методы были видны в редакторах без прокрутки

Кстати, я мог бы предложить изменить язык. « Создание нового метода » звучит как добавление чего-либо к коду и его увеличение и усложнение. Но « извлечение метода » - это то, что действительно происходит, когда вы реорганизуете, как мы надеемся, превосходный дизайн. Предполагая, что вы все равно должны иметь эту функциональность, этот метод всегда был там, он был просто похоронен внутри другого ...

Answer 6

Вы должны почти всегда создавать новый метод при повторении кода.

Он удаляет повторяющийся код и самодокументируется, если вы выбираете хорошее имя.

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

Answer 7

В конечном счете, вы не хотите повторяться, согласно принципу СУХОЙ (который вы и несколько других людей уже упоминали). Это также зависит от языка, который вы используете. Многие объектно-ориентированные языки делают все эти методы общедоступными (например, Objective-C), поэтому вам нужно создавать только те функции, которые предназначены для вызова другими объектами. С другой стороны, многие языки, такие как Java, предоставляют частные функции, которые поддерживают концепцию группировки блоков кода в частные функции, которые на самом деле не предназначены для использования вне самого класса.

Answer 8

Большинство методов должны выполнять одну задачу.

Answer 9

Создать метод для выполнения конкретной задачи. Если метод увеличивается в размере, это означает, что у него есть некоторые подзадачи, поэтому выделите (реорганизуйте) подзадачи в новый метод.