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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

3. Глубина не более двух конструкций

   для (...) за(...) для (...) ПЛОХОЙ

4. Не более одного цикла подряд (один за другим).

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

Answer 3

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

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

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

Answer 9

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

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

Answer 10

Проверьте Чистый код Роберта Мартина, который покрывает это (среди прочего)