Pourquoi utiliser Facultatif dans Java 8+ au lieu des contrôles de pointeur null traditionnels?

Nous avons récemment migré vers Java 8. Maintenant, je vois des applications inondées d’ Optionalobjets.

Avant Java 8 (Style 1)

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

Après Java 8 (Style 2)

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employee = employeeOptional.get();
    System.out.println(employee.getId());
}

Je ne vois aucune valeur ajoutée Optional<Employee> employeeOptional = employeeService.getEmployee();lorsque le service lui-même renvoie facultatif:

Venant d'un environnement Java 6, je vois le style 1 comme plus clair et avec moins de lignes de code. Y at-il un avantage réel qui me manque ici?

Consolidé à partir de la compréhension de toutes les réponses et des recherches plus poussées sur le blog

Le style 2 ne va pas assez en Java 8 pour voir le plein bénéfice. Vous ne voulez pas du if ... usetout. Voir les exemples Oracle . En suivant leurs conseils, nous obtenons:

Style 3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

Ou un extrait plus long

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

Si vous utilisez Optionalune couche de "compatibilité" entre une ancienne API qui peut toujours être renvoyée null, il peut être utile de créer l'option Facultatif (non vide) à la dernière étape, afin de vous assurer que vous disposez de quelque chose. Par exemple, où vous avez écrit:

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

J'opterais pour:

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

Le point est que vous savez qu'il ya un employé non nul de service , de sorte que vous pouvez envelopper que dans un Optionalavec Optional.of(). Ensuite, lorsque vous appelez getEmployee()à ce sujet, vous pouvez ou non engager un employé. Cet employé peut (ou peut-être pas) avoir un identifiant. Ensuite, si vous vous retrouvez avec un identifiant, vous souhaitez l’imprimer.

Il n'y a pas besoin de vérifier explicitement toute null, présence, etc., dans ce code.

Il n’ya pratiquement aucune valeur ajoutée à avoir une Optionalvaleur unique. Comme vous l'avez vu, cela ne fait que remplacer un contrôle nullpar un contrôle de présence.

Il est énorme valeur ajoutée à avoir une Collectionde ces choses. Toutes les méthodes de diffusion en continu introduites pour remplacer les anciennes boucles de bas niveau comprennent les Optionalchoses et font ce qu’il faut faire à leur sujet (ne pas les traiter ou, au final, renvoyer un autre non défini Optional). Si vous traitez n articles plus souvent qu'avec des articles individuels (et que 99% de tous les programmes réalistes le font), le fait de prendre en charge de manière optionnelle les éléments présents constitue un énorme progrès. Dans le cas idéal, vous ne devez jamais vérifier null ni être présent.

Tant que vous utilisez Optionalcomme une API sophistiquée isNotNull(), oui, vous ne trouverez aucune différence avec la simple vérification null.

Choses que vous ne devriez PAS utiliser Optionalpour

En utilisant Optionaljuste pour vérifier la présence d'une valeur est mauvais code ™:

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

Les choses que vous devriez utiliser Optionalpour

Evitez qu'une valeur ne soit pas présente, en en produisant une lorsque cela est nécessaire lors de l'utilisation de méthodes d'API à renvoi nul:

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

Ou, si créer un nouvel employé coûte trop cher:

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

De plus, sachez à tout le monde que vos méthodes risquent de ne pas renvoyer de valeur (si, pour une raison quelconque, vous ne pouvez pas renvoyer une valeur par défaut comme ci-dessus):

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

Et enfin, il y a toutes les méthodes de type flux qui ont déjà été expliquées dans d'autres réponses, même si ce ne sont pas vraiment vous qui décidez d'utiliser, Optionalmais vous utilisez les informations Optionalfournies par quelqu'un d'autre.

Le point essentiel pour moi lors de l'utilisation de Optional est de rester clair lorsque le développeur doit vérifier si la fonction renvoie une valeur ou non.

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

Votre erreur principale est que vous envisagez toujours de manière plus procédurale. Ceci n'est pas conçu comme une critique de vous en tant que personne, c'est simplement une observation. Penser en termes plus fonctionnels va de pair avec le temps et la pratique. Par conséquent, les méthodes sont actuelles et donnent l’impression que les choses correctes les plus évidentes s’appellent à vous. Votre erreur mineure secondaire est la création de votre option dans votre méthode. Facultatif est conçu pour aider à documenter le fait que quelque chose peut ou non renvoyer une valeur. Vous pourriez ne rien obtenir.

Cela vous a conduit à écrire un code parfaitement lisible qui semble parfaitement raisonnable, mais vous avez été séduit par les viles tentacules jumelles qui se font et sont présentes.

Bien sûr, la question devient rapidement "pourquoi sont-ils présents et même y arriver?"

Une chose qui manque à beaucoup de gens ici, c'est que isPresent () est que ce n'est pas quelque chose qui est fait pour le nouveau code écrit par des gens pleinement conscients de l'utile dieu que sont les lambda, et qui aime le fonctionnel.

Cependant, il nous donne quelques (deux) bons, grands avantages glamour (?):

• Il facilite la transition du code hérité pour utiliser les nouvelles fonctionnalités.
• Il facilite les courbes d'apprentissage de facultatif.

Le premier est plutôt simple.

Imaginez que vous ayez une API qui ressemble à ceci:

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

Et vous aviez une classe héritée utilisant ceci en tant que tel (complétez les blancs):

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

Un exemple artificiel pour être sûr. Mais supporte avec moi ici.

Java 8 est maintenant lancé et nous nous efforçons de monter à bord. L’une des choses que nous faisons est donc de remplacer notre ancienne interface par quelque chose qui retourne facultatif. Pourquoi? Parce que, comme quelqu'un d'autre l'a déjà gracieusement mentionné: Cela élimine la question de savoir si quelque chose peut être nul ou non. Cela a déjà été souligné par d'autres. Mais maintenant nous avons un problème. Imaginez que nous ayons (excusez-moi pendant que je frappe alt + F7 une méthode innocente), 46 endroits où cette méthode est appelée dans un code hérité bien testé qui fait un excellent travail sinon. Maintenant, vous devez mettre à jour tous ces éléments.

C’est là que brille isPresent.

Parce que maintenant: Snickers lastSnickers = snickersCounter.lastConsumedSnickers (); if (null == lastSnickers) {lance la nouvelle NoSuchSnickersException (); } else {consumer.giveDiabetes (lastSnickers); }

devient:

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

Et ceci est un changement simple que vous pouvez donner au nouveau junior: il peut faire quelque chose d’utile, et il va pouvoir explorer le code en même temps. gagnant-gagnant. Après tout, quelque chose qui ressemble à ce modèle est assez répandu. Et maintenant, vous n'avez pas à réécrire le code pour utiliser des lambdas ou quoi que ce soit. (Dans ce cas particulier, ce serait trivial, mais je laisse penser au lecteur des exemples où ce serait difficile comme exercice.)

Notez que cela signifie que votre façon de faire est essentiellement une façon de traiter le code hérité sans faire de réécriture coûteuse. Alors, qu'en est-il du nouveau code?

Eh bien, dans votre cas, où vous voulez simplement imprimer quelque chose, vous feriez simplement:

snickersCounter.lastConsumedSnickers (). ifPresent (System.out :: println);

Ce qui est assez simple et parfaitement clair. Le point qui remonte lentement à la surface est qu’il existe des cas d’utilisation pour get () et isPresent (). Ils sont là pour vous permettre de modifier mécaniquement le code existant pour utiliser les nouveaux types sans trop y penser. Ce que vous faites est donc malavisé des manières suivantes:

• Vous appelez une méthode qui peut renvoyer null. L'idée correcte serait que la méthode retourne null.
• Vous utilisez les méthodes héritées du pansement pour traiter cette option, au lieu d'utiliser les nouvelles méthodes savoureuses qui contiennent la fantaisie lambda.

Si vous souhaitez utiliser facultatif comme simple contrôle de sécurité null, vous devez simplement procéder comme suit:

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

Bien sûr, la belle version de ceci ressemble à ceci:

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

En passant, bien que cela ne soit absolument pas nécessaire, je recommande d’utiliser une nouvelle ligne par opération, afin de faciliter la lecture. Facile à lire et à comprendre bat la concision tous les jours de la semaine.

Ceci est bien sûr un exemple très simple où il est facile de comprendre tout ce que nous essayons de faire. Ce n'est pas toujours aussi simple dans la vie réelle. Mais remarquez comment dans cet exemple, ce que nous exprimons sont nos intentions. Nous voulons OBTENIR l'employé, OBTENIR son identifiant et, si possible, l'imprimer. C'est la deuxième grande victoire avec Optional. Cela nous permet de créer un code plus clair. Je pense aussi que faire des choses comme créer une méthode qui fait beaucoup de choses pour pouvoir l’alimenter sur une carte est en général une bonne idée.

Je ne vois pas l'avantage dans le style 2. Vous devez toujours comprendre que vous avez besoin du contrôle nul et qu'il est maintenant encore plus volumineux et donc moins lisible.

Le meilleur style serait, si employeeServive.getEmployee () renverrait Facultatif et le code deviendrait alors:

Optional<Employee> employeeOptional = employeeServive.getEmployee();
if(employeeOptional.isPresent()){
    Employee employee= employeeOptional.get();
    System.out.println(employee.getId());
}

De cette façon, vous ne pouvez pas appeleremployeeServive.getEmployee (). GetId () et vous remarquez que vous devez gérer la valeur optionnelle d'une manière ou d'une autre. Et si, dans l'ensemble de votre méthode, les méthodes de la base de code ne renvoient jamais la valeur null (ou presque jamais avec des exceptions bien connues de votre équipe à cette règle), la sécurité contre NPE sera renforcée.

Je pense que le plus grand avantage est que si votre signature de la méthode retourne un Employeevous ne cochez NULL. Vous savez par cette signature qu'il est garanti de renvoyer un employé. Vous n'avez pas besoin de gérer un cas d'échec. Avec une option, vous savez que vous faites.

Dans le code que j'ai vu, certaines vérifications nulles n'échouent jamais car les utilisateurs ne veulent pas tracer dans le code pour déterminer si une valeur null est possible, ils lancent donc des vérifications nulles partout de manière défensive. Cela rend le code un peu plus lent, mais plus important encore, il le rend beaucoup plus bruyant.

Cependant, pour que cela fonctionne, vous devez appliquer ce motif de manière cohérente.

Ma réponse est: ne le fais pas. Au moins réfléchir à deux fois si c'est vraiment une amélioration.

Une expression (tirée d'une autre réponse) comme

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

semble être la bonne façon fonctionnelle de traiter les méthodes de retour initialement nullables. Ça a l'air sympa, ça ne jette jamais et ça ne vous fait jamais penser à gérer le cas "absent".

Il a l'air mieux que la façon à l'ancienne

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

ce qui montre qu'il peut y avoir des elseclauses.

Le style fonctionnel

• semble complètement différent (et est illisible pour les personnes qui ne l'utilisent pas)
• est une douleur à déboguer
• ne peut pas être facilement étendu pour traiter le cas "absent" ( orElsen'est pas toujours suffisant)
• induit en erreur en ignorant le cas "absent"

En aucun cas, il ne devrait être utilisé comme une panacée. S'il était universellement applicable, alors la sémantique de l' .opérateur devrait être remplacée par la sémantique de l' ?.opérateur , le NPE oublié et tous les problèmes ignorés.

Tout en étant un grand fan de Java, je dois dire que le style fonctionnel n'est qu'un substitut du pauvre homme Java à la déclaration

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

bien connu d'autres langues. Sommes-nous d'accord pour dire que cette déclaration

• n'est pas (vraiment) fonctionnel?
• est très similaire au code de style ancien, juste beaucoup plus simple?
• est beaucoup plus lisible que le style fonctionnel?
• est-ce que le débogueur est convivial?

Facultatif est un concept (un type d'ordre supérieur) issu de la programmation fonctionnelle. Son utilisation supprime la vérification de nullité imbriquée et vous sauve de la pyramide du destin.