Почему я должен передавать Boolean в качестве параметра вместо "boolean"?

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

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

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

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

Ответ 1

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

EDIT: перечитайте вопрос, если этот параметр boolean действительно существует для управления if (именно это и есть примитив), то использование объектной формы - просто пустая трата процессора времени и памяти. Я не могу думать о разумной причине, почему это должен быть объект, а не примитив.

Ответ 7

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

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

Ответ 8

Держите его простым. Использование Boolean:

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

Ответ 9

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

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

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

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

EDIT. Автобоксинг работает только в 1,5 +

Ответ 10

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