Избегайте чрезмерных параметров функции: центрируемый классом или центрируемый функцией подход?

Я не знаю. Это действительно зависит от того, каковы параметры . Не существует магического шаблона проектирования "заставить 20 параметров функции исчезнуть", который можно вызвать. Лучшее, что можно сделать - это рефакторинг кода. В зависимости от того, что представляют собой параметры, возможно, имеет смысл сгруппировать некоторые из них в класс параметров, или поместить все в один монолитный класс, или разбить все на несколько классов. Один из вариантов, который может сработать, это некая форма карри, передавая объекты по чуть-чуть за раз, каждый раз выдавая новый объект, на который может быть вызван следующий вызов, передавая следующую партию параметров. Особенно это имеет смысл, если некоторые параметры часто остаются одинаковыми при вызове.

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

Не зная реального значения вашего кода, невозможно сказать, как его лучше всего рефакторизовать.

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

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

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

Здесь - смежный вопрос, говорящий об этом с большим количеством респондентов

Если p1,p2 и т.д... на самом деле являются всего лишь опциями (флаги и т.д...), и совершенно не связаны друг с другом, то я бы выбрал второй вариант.

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

class Something {
   int p1, p3, p5 ...;
   void helper1a();
};

class SomethingElse {
   int p7, p9, p10 ...;
   void helper1b();
};

class Options {
   int p2, p4, ...
};

void foo(Something &s, SomethingElse & else, Options &options) {
  helper2(options);
  s.helper1a();
  else.helper1b();
}

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

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

class Point {
      private:
        int x, y
        void moveUp() {}
        void moveRight() {}
      public:
        void moveUpAndRight() {
          moveUp();
          moveRight();
        }
        // add constructor
    };

struct Point {
  int x, y;
};

void moveUp {}
void moveRight {}
void moveUpAndRight {
  moveUp {}
  moveRight {}
}

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

Если вы просто группируете связанные данные для доступа к ним в целях организации...

struct Dwarves {
  int Doc, Grumpy, Happy, Sleepy, Bashful, Sneezy, Dopey;
}

void killDwarves(Dwarves& dwarves) {}
void buryDwarves(Dwarves& dwarves) {}

void disposeOfDwarves(Dwarves& dwarves) {
  killDwarves(dwarves);
  buryDwarves(dwarves);
}

Тогда имеет смысл использовать Подход 2.

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

Опция № 2.

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

Затем вы можете создавать экземпляры этого объекта, передайте его в свою программу.

Обычно это может что-то вроде объекта приложения или объект сеанса и т. Д.