Параметры конструктора - правило большого пальца

Ответ 1

С учетом этого множества параметров нужно рассмотреть шаблон Эффективный Java Reloaded [pdf], презентация Джоша Блоха на JavaOne 2007. (Это также пункт 2 в Эффективный Java 2nd Edition, но у меня нет его под рукой, поэтому я не могу его процитировать.)

Ответ 2

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

Ответ 3

Code Complete 2 рекомендует довольно разумный предел семи параметров для любого метода.

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

Ответ 4

Я не думаю, что вы можете сказать, что соответствующее число - "семь, не более" или "пять".

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

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

Примером плохого конструктора является

public NightWatchman(int currentFloor, int salary, int hapiness) {...}

Здесь NightWatchman строится с некоторыми значениями по умолчанию, которые почти наверняка изменятся за короткое время. Кажется забавным, что объект рассказывается об их значениях в одном направлении, а затем имеет их в другом виде (через их сеттеры) в будущем.

Пример лучшего конструктора:

public GateWatchman(Gate watchedGate, boolean shootOnSight) {...}

Вратарь, наблюдающий сторожа, является необходимой информацией для того, чтобы существовало. В классе я бы отметил его private final. Я решил передать переменную shootOnSight в конструктор, потому что здесь важно, чтобы объект всегда знал, стрелять в грабителей. Здесь идентификатор используется как тип.

У меня мог бы быть класс с именем ShootingGateWatchman и PoliceCallingGateWatchman - то есть параметр интерпретируется как часть идентификатора объектов.

Ответ 5

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

Ответ 6

Обычно я бы сказал не более пяти, из 7 +/- 2 правила краткосрочной памяти, и некоторый пессимизм относительно внимание программиста. Примечание. Я считал бы varargs как один объект.

Если вам действительно нужно построить объект за один раз, вы можете обычно собирать связанные параметры в простых объектах значения и передавать их в конструктор. Попытайтесь убедиться, что объекты значения имеют некоторый концептуальный смысл и являются не просто случайными наборами информации...

Ответ 7

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

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

Для методов я стараюсь следовать рекомендациям из книги "Чистый код", чтобы иметь не более 3 параметров для каждого метода (IIRC). Для конструкторов у меня может быть больше параметров, потому что, как правило, конструктор будет вызван моей инфраструктурой инъекции зависимостей, а не мной.

Рисунок строителя, упомянутый mmyers, также является хорошим решением при создании сложных объектов, и нет способа сделать их менее сложными.

Ответ 8

Это зависит.

Если некоторые параметры одного типа и могут быть перепутаны, я бы допустил довольно небольшое число (скажем, 5).

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

Ответ 9

Как передать в объект Param = > Value Map конструктору? Если вызывающий абонент пропускает какие-либо критические параметры, создайте конструктор для исключения Exception.

Это означает, что неправильные вызовы конструктора будут вызываться только во время выполнения, а не во время компиляции, что является недостатком. Но подход getter/setter имеет ту же проблему, и с этим должно быть намного проще работать.