Почему я должен передавать логический параметр вместо «логический»?

Question

Сотрудник попросил меня сменить подпись с использования примитивного "логического" на использование классифицированного "логического". Он не дал очень хорошего объяснения, почему?

Кто-нибудь из вас слышал об этом и может ли кто-нибудь из вас объяснить, почему это важно или не важно?

Редактировать: он упомянул, что это хорошая практика для публичных методов.

Использование поля - это просто флаг, который говорит мне, вызывать ли тот или иной поток в зависимости от того, является ли он истинным или ложным.

Answer 1

Это связано с базой данных? Если у вас есть логическое значение в базе данных, оно может содержать одно из трех значений - true, false и null. Логический объект позволит вам подражать этому поведению.

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

Answer 2

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

Answer 3

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

В ответ на ваши изменения я никогда не слышал о том, чтобы это было хорошей практикой для публичных методов. В часто цитируемой книге «Эффективная Java» Джоша Блоха есть целый пункт «Предпочитать примитивные типы примитивам в штучной упаковке» (пункт 49, если вы можете достать копию). Похоже, в вашем конкретном случае нет причин предпочитать использовать булево-логическое выражение big-b, а использование объектов создает ловушки, такие как плохое взаимодействие со старым кодом, который, например, использует == вместо equals() (что даже не возможно для примитива).

Answer 4

Основным преимуществом Boolean перед примитивными логическими значениями является то, что они позволяют иметь нулевое значение. Это особенно эффективно для возвращаемых значений, но иногда может использоваться для «необязательного» аргумента в Java.

Убедитесь, что ваши JavaDocs (и код) могут иметь значение null

Answer 5

Никогда не слышал ни о какой веской причине, чтобы предпочесть Boolean более boolean.

Если есть шанс, всегда придерживайтесь примитивов. Булевы переменные могут быть null; и, таким образом, может привести к неожиданному поведению в вашем методе. У вашего коллеги могут быть некоторые конкретные причины, основанные на реализации / логике программы.

Answer 6

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

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

РЕДАКТИРОВАТЬ: перечитывая вопрос, если этот параметр boolean действительно просто для управления if (именно для этого и существует примитив), то использование формы объекта просто пустая трата ЦП. время и память. Я не могу придумать разумную причину, почему это должен быть объект, а не примитив.

Answer 7

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

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

Answer 8

Будьте проще. Использование логического значения:

• добавляет дополнительный уровень сложности
• принимает логическое состояние true / false и преобразует его в переменную состояния true / false / null
• не дает никаких преимуществ, если используется в качестве логического флага (при условии отсутствия взаимодействия с базой данных, как упомянуто BlairHippo)
• потенциально требует дополнительных строк кода для включения / выключения логических значений в Java 1.4

Answer 9

Используете ли вы какие-либо рамки привязки данных в вашем приложении? Недавно мне пришлось столкнуться со случаем, когда boolean в модельном объекте нужно было связать с формой. Поле в форме было обязательным, но мы не хотели устанавливать значение по умолчанию true или false (поскольку для пользователя было важно выбрать правильное значение для конкретного случая, если по умолчанию вы легко получите много неправильных значений.) Однако, прежде чем объект мог быть проверен, значения из формы должны были быть привязаны к нему. Конечно, если пользователь не выбрал значение, он попытается привязать null к полю, и во время привязки будет сгенерировано исключение. Поэтому мы изменили его на Boolean, чтобы null можно было временно привязать к полю, а затем проверка могла бы сообщить, что поле является обязательным.

Answer 10

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

public void setX(boolean b) //only takes boolean

public void setX(Boolean b) //takes Boolean or boolean

Это связано с автобоксом логических значений в функцию.

РЕДАКТИРОВАТЬ : автобокс работает только в 1,5 +