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

Question

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

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

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

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

Answer 1

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

Answer 6

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

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

Answer 7

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

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

Answer 8

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

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

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

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

EDIT: Autoboxing работает только в 1.5+

Answer 9

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

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

Answer 10

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