Количество параметров для конструктора

Ответ 1

12 параметров звучат для меня слишком много. Варианты уменьшения их числа:

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

2. Представьте Builder (опционально с цепочкой методов). Это не уменьшает фактический список параметров, но делает код более читабельным и особенно полезно, если у вас есть несколько различных сценариев создания с различными параметрами. Так что вместо

   MyClass someObject = new MyClass(aFoo, aBar, aBlah, aBaz, aBorp, aFlirp, 
           andAGoo);
   MyClass anotherObject = new MyClass(aFoo, null, null, aBaz, null, null, 
           andAGoo);
   

   вы можете иметь

   MyClass someObject = new MyClassBuilder().withFoo(aFoo).withBar(aBar)
           .withBlah(aBlah).withBaz(aBaz).withBorp(aBorp).withFlirp(aFlirp)
           .withGoo(aGoo).build();
   MyClass anotherObject = new MyClassBuilder().withFoo(aFoo).withBaz(aBaz)
           .withGoo(aGoo).build();
   

3. (Может быть, мне следовало начать с этого ;-) Анализировать параметры - действительно ли все они необходимы в конструкторе (то есть обязательно)? Если параметр является необязательным, вы можете установить его через обычный установщик вместо конструктора.

Ответ 2

Если ваша функция принимает одиннадцать параметров, вы, вероятно, забыли еще один

Мне нравится это предложение, потому что оно суммирует все: плохой дизайн вызывает плохой дизайн.

Я взял это из книги Стандарты кодирования С++: 101 Правила, рекомендации и лучшие практики Херб Саттер, Андрей Александреску.

Изменить: прямая цитата. Если у вас есть процедура с десятью параметрами, вы, вероятно, пропустили некоторые. Это цитата из Алана Перлиса.

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

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

Обратите внимание на этот вопрос: Сколько параметров слишком много?

Ответ 3

12 Параметры, скорее всего, неправильно с дизайном.

Что делается с параметрами?

• Класс просто отправляет их в другие конструкторы? Тогда, возможно, он должен просто принимать интерфейсы к готовым конструированным объектам.
• Является ли класс большим и делает много вещей со всеми этими параметрами? Затем класс несет большую ответственность и должен принимать классы, которые заботятся о деталях.
• Существуют ли какие-либо "кластеры" в параметрах? Возможно, некоторые из параметров являются классом в создании. Инкапсулируйте их и дайте им соответствующую ответственность.

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

Ответ 4

если возможно, вы можете группировать параметры по классам и передавать их экземпляры конструктору.

Ответ 5

Я думаю, что это может быть приемлемо при использовании шаблона State, например. Однако могу ли я предложить передать объект (если необходимо), чтобы эти параметры появились? А потом в конструкторе загрузите данные из него?