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

Ответ 1

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

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

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

Ответ 2

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

Тем не менее, есть несколько правил большого пальца (которые не не отменяет мои инстинкты).

• Если вам нужно прокрутить экран, чтобы прочитать один метод, вам нужно разбить его

• Если у вас есть deja vue (код, который вы пишете, кажется знакомым), вы, вероятно, повторяетесь сами, это означает, что вы должны иметь существующую функцию/метод и не писать новый.

• Не более двух конструкций глубоких

  для (...) для(...)   для (...) BAD

• Не более одного цикла в строке (один за другим).

• Если вам нужно вернуть более одного типа данных (нулевая/ложная версия - нет), вам нужно что-то разбить.
• Если вы запутались при чтении своего метода - разделите его
• Метод/функция должен отвечать за одну задачу.
• Самое очевидное - при написании новых функций: -)

Ответ 3

Интересный момент, хотя и не связанный с объектно-ориентированным программированием, выполнен в стиле кодирования linux guide:

Глава 4: Функции

Функции должны быть короткими и приятными, и делать только одно. Они должны соответствовать одному или двум экранам текста (размер экрана ISO/ANSI равен 80x24, как мы все знаем), и делать одно и делать это хорошо.

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

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

Другой мерой функции является количество локальных переменных. Они не должны превышать 5-10, или вы делаете что-то неправильно. Переосмыслить функцию и разбить ее на более мелкие части. Человеческий мозг обычно может легко отслеживать около 7 разных вещей, что-то еще, и он запутывается. Вы знаете, что вы великолепны, но, возможно, вам хотелось бы понять, что вы сделали через 2 недели.

Ответ 4

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

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

Ответ 5

Вы можете извлечь метод, если:

• есть блок комментариев для фрагмента
• вы можете назвать намерение фрагмента

Ответ 6

Помимо отличного ответа от Graviton, я рекомендую другое эмпирическое правило, чтобы решить, когда создать новый метод:

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

Ответ 7

Я думаю, что это очень субъективный вопрос без реального ответа. Различные ситуации требуют разных решений, и не будет ни одного рецепта "когда создавать новый метод". Это зависит.

Ответ 8

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

Ответ 9

Отметьте "Чистый код" Роберта Мартина, который охватывает это (между прочим)

Ответ 10

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

как для книг: шаблоны проектирования (Gamma, Vlissides, Johnson, Helm), книги Фаулера (рефакторинг, шаблоны архитектуры корпоративных приложений), книги Бэка (разработка с использованием тестовых примеров с примерами, шаблоны реализации) и т.д.

Ответ 11

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

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

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

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

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

Ответ 12

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

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

Ответ 13

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

Ответ 14

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

Ответ 15

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

Ответ 16

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

Ответ 17

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

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

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

Ответ 18

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

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

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

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

Ответ 19

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