Où faut-il utiliser Optional, et où est-ce une erreur ?

Optional a été conçu comme un type de retour pour les méthodes qui peuvent légitimement n'avoir aucun résultat, afin que l'appelant ne puisse pas ignorer l'absence. Il convient mal aux champs, aux paramètres de constructeur et aux arguments de méthode, et il ne doit pas envelopper une collection, puisqu'une liste vide dit déjà qu'il n'y a rien. Appeler get sans vérifier annule tout l'intérêt ; utilisez map, filter, orElseGet ou orElseThrow avec une exception qui a du sens.

Il existe pour qu'une signature de méthode puisse dire ceci peut ne rien renvoyer, ce qu'un type de retour nullable n'a jamais communiqué. Donc les recherches de type repository renvoient un Optional et l'appelant est obligé de s'en occuper. Ça dérape quand les gens en mettent partout. En champ, il ajoute un objet par instance et n'est pas sérialisable, ce qui cause de vrais problèmes dans les entités et les payloads. En paramètre, il donne juste aux appelants trois états à considérer au lieu de deux, donc j'utilise plutôt une surcharge. Et une méthode qui renvoie une collection renvoie une collection vide, jamais un Optional de liste, parce que vide signifie déjà la même chose. Côté style, si j'écris isPresent suivi de get, je viens d'écrire un test de null avec du cérémonial en plus, donc je chaîne à la place : map vers ce que je veux, filter, puis orElseThrow avec une exception métier qui dit quel id est introuvable. La seule chose que je ne ferais pas, c'est l'utiliser comme remplacement générique de null sur une base de code existante, puisque le style mixte est pire que l'une ou l'autre convention seule.