Плохая практика использования 5 различных параметров метода?

Question

У меня есть две кнопки, каждая из которых может выполнять две разные реализации (независимо от того, выбрана она или нет), так что это всего 4 возможных реализации. После кодирования всего, я заметил, что у меня было 20 строк кода для каждой реализации, и только 1 или 2 переменных были разными в каждом. Я решил, что хочу очистить это, и каждый вызов реализации каждого разного, более мелкие методы и передавать непоследовательные переменные в качестве параметров.

Я полагаю, что это лучшая практика b/c Я использую код повторно. Однако в одном из моих методов я должен передать 5 различных аргументов, реализующих метод с правильными условиями.

Имеет ли это много параметров в методе плохой практики?

Answer 1

Это один из тех субъективных вопросов, который действительно трудно ответить окончательно.

Я не возражаю против нескольких параметров в методе Objective C, поскольку он может сделать API более понятным (и параметры могут быть хорошими &).

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

Answer 2

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

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

Answer 3

Имея много параметров, не нужно плохое.

Существуют шаблоны, которые создают класс для группировки всех параметров в один объект, который может казаться вам более чистым. Другой альтернативой является использование словаря для всех параметров в качестве единственного параметра конфигурации. Некоторые из классов яблок делают это (например, title font configuration in the navigation bar).

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

Answer 4

Не существует определенного количества параметров, которые обычно являются «плохой практикой». Метод должен иметь столько параметров, сколько необходимо. Тем не менее, бывают случаи, когда наличие большого количества параметров может указывать на то, что лучший дизайн может быть возможен. Например, есть случаи, когда вы можете понять, что объект должен отслеживать некоторое значение в переменной-члене, а не каждый раз, когда значение передается в его методы.

Answer 5

Я думаю, что это нормально использовать 5 Params, потому что некоторые Objective-C по умолчанию метод также с 4 Params как

[[NSNotificationCenter defaultCenter] addObserver:self 
             selector:@selector(updateConvMenu:) 
           notificationName:@"NSConvertersChanged" 
              object:converterArray]; 

Что мы можем сделать, чтобы сделать его более ясным, дает лучший формат кода

Answer 6

отказ от ответственности: Я знаю пшик о Objective C

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

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

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

• завернуть наступательный метод с несколькими более лаконичными методами. Вы можете создать, например, метод для каждой из ваших «реализаций», с хорошим именем, указывающим его назначение, которое принимает только аргументы, необходимые для этой цели. Затем он передал бы внутренний, более приятный метод. Метод smelly будет использоваться только в ваших «специфичных для реализации» оболочках вместо того, чтобы разбросаться по всему вашему коду. Используя вместо этого хорошо зарекомендовавшие себя оболочки, разработчики поймут ваши намерения, не расшифровывая значения параметров.

• Создайте класс, который инкапсулирует данные, необходимые для этого метода. Если то, что метод делает, зависит от состояния какой-либо системы или подсистемы, тогда инкапсулируйте это состояние! Я часто это делаю с классами типа «XXContext». Теперь ваш метод может проверять и анализировать эти контекстуальные данные и предпринимать соответствующие действия. Это хорошо для рефакторинга. Если метод в будущем нуждается в дополнительной информации для выполнения своих задач или реализации новых функций, вы можете добавить эти данные к объекту аргумента, вместо того чтобы изменять каждый бит кода, который использует этот метод. Только код, который должен использовать изменения, должен будет предоставить соответствующие значения контекстуальным данным.