Много раз на протяжении написания более крупных программ я спрашивал, сколько копий и вставок имеет смысл помещать код в функцию или метод и каково хорошее практическое правило? Я использовал эмпирическое правило из четырех или более строк и появлялся более двух раз, затем я сделал простую функцию / метод, содержащий этот код. Можете ли вы придумать лучшую практику или предложить какие-либо указатели? Это скорее вопрос общего шаблона проектирования, а не вопрос конкретного языка.
Ответы:
Я использую функции частично как способ документировать код. Вызов функции со значимым именем облегчает понимание кода. В некоторых случаях даже функция с одной строкой имеет смысл.
Например, в «Чистом коде» Роберт С. Мартин приводит следующий пример: какой из них вы бы предпочли увидеть? Эта:
// Check to see if the employee is eligible for full benefits
if ((employee.flags & HOURLY_FLAG) &&
(employee.age > 65))
Или это?
if (employee.isEligibleForFullBenefits())
Я не всегда согласен с ним, но в этом случае я согласен. Код должен быть читаемым, не только когда вы его пишете и знаете все детали, но и в 21:00, когда вам нужно исправлять ошибки в чужом коде. Не рекомендуется смотреть на длинные условия и пытаться выяснить все двойные негативы. Если вы можете просто указать имя (не только условия, но и каждый фрагмент кода, который вы пишете), это станет намного проще.
Я никогда не жалел, что что-то вставил в функцию, и если вы беспокоитесь о производительности, то сначала профиль.
Существует широко распространенное заблуждение, что вызовы функций должны выполняться только во избежание повторяющихся сегментов кода. Мое эмпирическое правило заключается в том, что любая логическая единица работы должна быть превращена в функцию, даже если она используется только в одном месте. Это обычно приводит к лучшей читабельности и позволяет писать самодокументируемый код, где имена функций заменяют комментарии, и вам не нужно писать дополнительные комментарии, объясняющие, что вы делаете.
Если он используется более чем в одном месте, и
затем сделайте это функцией или методом. Длинные фрагменты повторяющегося кода, по моему опыту, естественным образом попадут в одну из этих категорий (обычно первую, но затем категории сильно пересекаются;). Конечно, все, что должно быть в интерфейсе, также является функцией / методом само по себе.
float x, int yи double density, тогда настройка этих вычислений как функции C может быть сложнее, чем просто повторять код, поскольку вам нужно найти способ получить все три значения. Если сами повторяющиеся вычисления тривиальны, иногда лучше просто оставить их встроенными.
Почти всегда, особенно если каждый дубликат представляет одну и ту же операцию с концептуальной точки зрения. Если это выполняется одинаково, но для разных типов, сделайте общую реализацию.
Единственная причина, по которой я не могу придумать, - это обслуживание: иногда было бы удобнее избегать создания зависимости между отдельными вещами, даже за счет некоторого дублирования.
Поиск « рефакторинга » приведет вас ко многим ресурсам отраслевых «лучших практик» для этого очень распространенного процесса. Несколько известная статья, « Однажды и только один раз», является отличным историческим справочником, объясняющим то, что некоторые считают «лучшими практиками» для вопросов, поднятых вашим вопросом. Кроме того, еще более общая концепция известна как « Не повторяйся» (СУХОЙ) . Чтобы получить действительно исчерпывающий набор ответов на ваш вопрос, прочитайте замечательную классику Мартина Фаулера « Рефакторинг: улучшение дизайна существующего кода» , которая охватывает некоторые из самых известных советов по рефакторингу , и это то, что вы интуитивно пытаетесь выполнить. !
Это зависит от характера сплоченности повторяющегося кода. Если повторяющаяся часть кода выполняет определенную функцию, то она является отличным кандидатом на включение в метод, частично из-за принципа СУХОЙ , частично потому, что если функцию необходимо оптимизировать или исправить, то существует только один раздел кода для решения.
Если это совпадение, лучше повторить код, а не превращать его в метод. Если вам нужно добавить что-то в середину одной из последовательностей кода, чтобы удовлетворить одно из применений этого фрагмента, если он находится в методе, внесенные вами изменения могут повлиять на другие применения этого метода.
Смотрите статью в Википедии о концепции связности кода .
Вы должны различать функции в смысле структурированного программирования и методы класса.
В вашем примере вы показали, что метод как таковой не должен быть закодирован как in-line.
вам, возможно, придется проверить строку, чтобы увидеть, является ли она числом или нет, в этом случае вы используете функцию и большинство предыдущих ответов применимы.
Это различие особенно важно в крупных проектах.
Постарайтесь отделить бизнес-правила (которые являются методами) от вычислительных алгоритмов (которые являются чисто программными функциями).