Basierend auf einer Entdeckung in einem unserer Projekte habe ich eine spannende Diskussion mit zwei KollegInnen im Team geführt.
Im Code wurde if (optional.isPresent()) {
verwendet, um dann mit optional.get()
den Wert zu verwenden. Mein Vorschlag, besser ifPresent(...)
zu verwenden, führte dann zu den erwähnten Diskussionen.
Zur Verdeutlichung habe ich nachfolgend eine vereinfachte Version beider Möglichkeiten:
class Scratch {
public static void bad() {
var optional = Optional.of("ABC");
if (optional.isPresent()) {
System.out.println(optional.get());
}
}
public static void good() {
var optional = Optional.of("ABC");
optional.ifPresent(value -> {
System.out.println(value);
});
}
}
isPresent()
wurde, meinen Recherchen zufolge, dafür konzipiert, dem Nutzer von Optionals eine Möglichkeit zu geben, auf das Vorhandensein zu reagieren, ohne unbedingt den tatsächlichen Wert zu benötigen.
ifPresent()
(oder analog ifPresentOrElse()
) soll (auch laut ApiDoc) dazu verwendet werden, um etwas mit dem Wert zu tun, wenn er denn vorhanden ist.
Mein Lieblingskommentar dazu war, dass die erste Variante keine funktionale Programmierung sei. Dicht gefolgt von der Aussage, dass die zweite Variante besser zu lesen/verstehen sei.
Schauen wir uns die Implementierung von ifPresent() an, wird das Ganze interessanter:
public void ifPresent(Consumer<? super T> action) {
if (value != null) {
action.accept(value);
}
}
Man kann jetzt argumentieren, der Einsatz von ifPresent
führt nur dazu, dass man das oben zu sehende if (optional.isPresent)
eine Ebene weiter unten versteckt. Es ist dann eigentlich unnötig, diese zusätzliche Abstraktion zu gehen.
Mein Fazit ist daher: Ich finde den Einsatz von ifPresent()
optisch schöner und soweit ich das verstanden habe, war auch der Einsatz in dieser Form von den „Erfindern“ vorgesehen.