Wo sollte Optional eingesetzt werden, und wo ist es ein Fehler?

Optional wurde als Rückgabetyp für Methoden entworfen, die legitim kein Ergebnis haben können, damit der Aufrufer die Abwesenheit nicht ignorieren kann. Für Felder, Konstruktorparameter und Methodenargumente passt es schlecht, und es sollte keine Collection umhüllen, denn eine leere Liste sagt bereits, dass da nichts ist. get ohne Prüfung aufzurufen macht den Sinn kaputt; nimm map, filter, orElseGet oder orElseThrow mit einer aussagekräftigen Exception.

Es existiert, damit eine Methodensignatur sagen kann, hier kommt vielleicht nichts zurück, was ein nullbarer Rückgabetyp nie kommuniziert hat. Repository-artige Lookups geben also ein Optional zurück und der Aufrufer muss sich damit auseinandersetzen. Schiefgehen tut es, wenn Leute es überall hinpacken. Als Feld kostet es ein Objekt pro Instanz und ist nicht serialisierbar, was in Entities und Payloads echte Probleme macht. Als Parameter gibt es Aufrufern nur drei Zustände zum Nachdenken statt zwei, dafür nehme ich lieber eine Überladung. Und eine Methode, die eine Collection liefert, gibt eine leere Collection zurück, niemals ein Optional einer Liste, denn leer bedeutet bereits dasselbe. Stilistisch gilt: schreibe ich isPresent gefolgt von get, habe ich gerade einen Null-Check mit Extra-Zeremonie geschrieben, also verkette ich stattdessen: map auf das, was ich will, filter, dann orElseThrow mit einer Domain-Exception, die sagt, welche id nicht gefunden wurde. Was ich nicht tun würde, ist es als generellen Null-Ersatz quer durch eine bestehende Codebase zu ziehen, denn der Mischstil ist schlimmer als jede der beiden Konventionen allein.