Не используйте Optional для условной логики.

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

То, что вы можете красиво связать их в одну строку, не означает, что это понятно. Кроме того, вы буквально ничего не получаете. Накладные расходы на производительность может быть значительны. В худшем случае N объекты создаются, а затем удаляются. Просто оставайтесь со своими «обычными» if-else цепями.

Вместо того, чтобы искать способы сделать ваш текущий код более читабельным, сделайте шаг назад и спросите себя Зачем, вам нужно 15-20 операторов if-else. Можете ли вы разделить некоторую логику? Зачем вообще нужен геттер для стольких разных полей с потенциально разными типами? и т.п.

Есть и третья форма (допускающая еще некоторые вариации).

return Stream.<Supplier<Object>>of(message::getA, message::getB, message::getC)
        .map(Supplier::get)
        .filter(Objects::nonNull)
        .findFirst()
        .orElse(null);

Вероятно, наименее гибкий и эффективный на данный момент, но понятный.

тл;др

Если ваша цель — сжатый код, используйте троичную цепочку. Производительность, вероятно, идентична серии операторов if-then-else.

        ( this.getA() != null ) ? this.getA()
                : ( this.getB() != null ) ? this.getB()
                : ( this.getC() != null ) ? this.getC()
                : null;

Тернарная цепочка

Как правильно указано в Ответ от Лино, вы пытаетесь вывести Optional за пределы их первоначальной цели (возвращая значения в лямбда-выражениях и потоках). Как правило, лучше всего использовать Optional только с оператором return и только тогда, когда вы хотите прояснить, что null является допустимым значением для возврата. См. этот ответ Брайана Гетца.

тернарный оператор — это сжатый if-then-else, объединенный в однострочный.

result = test ? valueToUseIfTestIsTrue : valueToUseIfTestIsFalse

Пример:

Color color = isPrinterMonochrome ? Color.GREY : Color.GREEN ; 

Используйте цепочку троичных операторов.

Итак, это:

    if ( this.getA() != null )
        return this.getA();
    else if ( this.getB() != null )
        return this.getB();
    else if ( this.getC() != null )
        return this.getC();
    else return null;

… становится следующим:

    return
            ( this.getA() != null ) ? this.getA()
                    : ( this.getB() != null ) ? this.getB()
                    : ( this.getC() != null ) ? this.getC()
                    : null;

Пример кода.

public String getA ()
{
    // return "A";
    return null;
}

public String getB ()
{
    // return "B";
    return null;
}

public String getC ()
{
    return "C";
    // return null;
}

public String getABC ()
{
    if ( this.getA() != null )
        return this.getA();
    else if ( this.getB() != null )
        return this.getB();
    else if ( this.getC() != null )
        return this.getC();
    else return null;
}

public String getABCTernary ()
{
    return
            ( this.getA() != null ) ? this.getA()
                    : ( this.getB() != null ) ? this.getB()
                    : ( this.getC() != null ) ? this.getC()
                    : null;
}

Запустите этот пример кода.

String s = this.getABCTernary();
System.out.println( "s: " + s );

C

Плюсы и минусы

• Преимущество троичной цепочки — сжатый код, свернутый в одну строку.
• Недостатком является то, что в этой конкретной ситуации вы дважды вызываете свой метод получения только для того, чтобы получить одно значение. Это не проблема для простого метода получения переменной, но влияет на производительность, если метод получения требует много времени, например вызов удаленных веб-служб. И каскадный if-then-else имеет ту же проблему, также вызывая ваш геттер дважды.

Представление

how these two compare in terms of performance

Тернарный оператор в Java — "короткое замыкание", что означает, что левая или правая сторона, которая соответствует результатам теста, является единственным вызываемым кодом. В нашем коде здесь, если getA возвращает ненулевое значение, это значение возвращается немедленно. Дальнейшие вызовы getB и getC никогда не выполняются. Так что в этом отношении производительность цепочечной тройки такая же, как у каскадного оператора if-then-else: выигрывает первое совпадение, дальнейших вызовов нет.

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

Пару дней назад я провел тщательный анализ производительности. Это оказывает огромное влияние на производительность. С AdoptOpenJDK операторы if выполняются до 10 раз быстрее. Когда JIT-компилятор работает в горячем режиме, штраф снижается до 20%.

GraalVM работает лучше: 3-кратное замедление с холодной JVM, и после того, как компилятору дается достаточно времени, чтобы сделать свое волшебство, также снижается производительность на 20%.

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

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

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

Я знаю, что это полностью противоречит общественному мнению.

Однако это необходимо осознать каждому...

1. То, что читается одним человеком, не обязательно читается другим. Даже в этой ветке у нас разные мнения о том, читабельнее ли if или Optional. Такого рода дебаты будут происходить независимо от того, в каких конструкциях или ситуациях мы находимся.
2. Если мы возьмем вариант if, который более эффективен, чем функциональный подход, каждый и каждый раз, то люди, читающие этот код, привыкнут к нему и найдут его БОЛЕЕ ЧИТАЕМЫЙ — потому что это стиль, к которому они теперь привыкли.
3. Эффективный код не обязательно должен быть «сложным для чтения»… но это возвращает нас к пунктам 1 и 2. Разработчики должны действительно знать основы языка, который они используют, и писать код, подходящий для этого языка. , а не пытаться формировать «английские предложения» в своем коде.

Итак, по сути: идите с if... используйте НЕТ это Optional!