Является ли использование Optional.ofNullable в качестве замены троичного оператора хорошей практикой? - PullRequest
0 голосов
/ 27 ноября 2018

Рассмотрим использование этого выражения:

String hi = Optional.ofNullable(sayHi()).orElse("-");

, которое эффективно соответствует этому троичному выражению:

String hi = sayHi() != null ? sayHi() : "-";

Является ли это использование Optional.ofNullable с вызовом метода хорошей практикой?Или просто дополнительное подробное кодирование?


Я понимаю, что Optional.ofNullable фактически создает переменную и избегает вызова метода sayHi() дважды.Чтобы избежать этой проблемы, вы могли бы создать дополнительную переменную, но это добавляет многословности троичного параметра:

String hi = sayHi();
hi = hi != null ? hi : "-";

С другой стороны, Optional.ofNullable создает в случае, если hi не является nullдополнительный Optional объект.Так что наверняка есть дополнительные издержки.

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


Кстати:это реализация Java 8 Optional.ofNullable:

public static <T> Optional<T> ofNullable(T value) {
    return value == null ? empty() : of(value);
}

Ответы [ 6 ]

0 голосов
/ 29 ноября 2018

В JDK 9 или новее используйте это:

String hi = Objects.requireNonNullElse(sayHi(), "-");

Это позволяет избежать необходимости повторять sayHi(), если используется троичный оператор, или назначать его значение локальной переменной, которая повторно используется втройная.Это может быть небольшое улучшение.Это также обходит вопрос, использовать ли Optional.: -)

0 голосов
/ 29 ноября 2018

Вкратце: избегайте типа Optional.Основной аргумент для Optional в типах возврата: «Клиентам слишком легко забыть обработать возможность нулевого возвращаемого значения. Optional уродливо и прямо перед вами, поэтому клиент с меньшей вероятностью забудет обработатьвозможность пустого возвращаемого значения. В любом другом месте программисты должны продолжать использовать обычные ссылки, которые могут быть нулевыми. "

Я написал обсуждение плюсов и минусов использования типа Optional в Java: Нет ничего лучше, чем тип Optional .

0 голосов
/ 27 ноября 2018

Я думаю, что это в основном дело личного вкуса.

С моей точки зрения, было бы более разумным просто вернуть Optional<String> и позволить вызывающей стороне справиться с отсутствующим значением.

Необязательно, будучи монадическим типом, его можно использовать не только для получения значения alt.

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

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

0 голосов
/ 27 ноября 2018

Является ли использование Optional.ofNullable с вызовом метода хорошей практикой?

Концептуально , это плохая практика.Основная идея состоит в том, чтобы представлять отсутствие возвращаемого значения, а не оборачивать все, что может быть null.Я категорически против этого использования.

Или просто подробное кодирование?

Мне кажется, что неудачная попытка сделать ваш код более модным.(«Посмотрите, мы используем совершенно новый Optional из Java 8!»)

Я предпочитаю удобочитаемость и ясность, а не лаконичность.

Такое использование Optinal не дает ясности, ноподнимает вопросы:

Зачем вы оборачиваете переменную?
Что вы собираетесь делать с этим Optional?
Будет ли оно использоваться / возвращаться ниже?

Это также не дает краткости: ваша вторая строка еще короче.

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

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

String hi = (hi = sayHi()) != null ? hi : "-";

Хотя, ваше предложение в две строки совершенно нормально:

String messageContent = sayHi();
String hi = messageContent != null ? messageContent : "-";
0 голосов
/ 27 ноября 2018

Всякий раз, когда я задумываюсь об использовании Дополнительного API для конкретной цели, я всегда напоминаю себе о том, что он должен был делать и почему он был внесен в JDK, а именно:

Необязательно внамеревался обеспечить ограниченный механизм для возвращаемых типов библиотечных методов, когда существует явная необходимость представлять «нет результата», и где использование null для этого в подавляющем большинстве случаев может привести к ошибкам - Стюарт Маркс

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

Использование этой конструкции, как в этом конкретном примере, приводит к дополнительному выделению памяти и накладным расходам GC.

Я бы все упростил и вместо этого сделал:

String hi = sayHi();
if(hi == null) hi = “-“;
...
0 голосов
/ 27 ноября 2018

Если вы собираетесь разрешить Optional в своем рабочем процессе, вам следует рассмотреть возможность изменения метода sayHi(), чтобы он возвращал Optional<String>, что сделает результат более элегантным:

hi = sayHi().orElse("-");

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

Что касается затрат на производительность Optional (таких как увеличение сбора мусора), вам нужно будет профилировать свое приложение и решить, действительно ли это было проблемой.

Дополнительно, если вы в основномесли вы заинтересованы в String, то вам следует помнить о методе Objects.toString(Object, String), который возвращает значение по умолчанию, если объект имеет значение null:

hi = Objects.toString(hi, "-");

Это более аккуратно и элегантно, чем писать код вручную.

...