[JAVA] Pensez aux 7 règles d'Optionnel

Aperçu

Lors de la conférence Devoxx US 2017 à laquelle j'ai assisté l'autre jour, j'ai appris les règles de gestion de l'Optionnel, donc j'écrirai ce que j'ai pensé en le résumant.

7 règles d'Optionnel

Mr.Stuart Marks (@stuartmarks) "Facultatif - La mère de tous les bikesheds / Facultatif - The_Mother_of_all_Bikesheds) "a été suivi. Là, sept règles ont été introduites lors de l'utilisation de java.util.Optional. ..

1. Never, ever, use null for an Optional variable or return value.
2. Never use Optional.get() unless you can prove that the Optional is present.
3. Prefer alternatives to Optioal.isPresent() and Optional.get().
4. It’s generally a bad idea to create an Optional for the specific purpose of chaining methods from it to get a value.
5. If an Optional chain has a nested Optional chain, or has an intermediate result of Optional, it’s probably too complex.
6. Avoid using Optional in fields, method parameters, and collections.On a related note, I thought of another rule after I presented the session:
7. Don’t use an Optional to wrap any collection type (List, Set, Map). Instead, use an empty collection to represent the absence of values.

Veuillez vous référer aux documents ci-dessous (sauf pour la règle 7) pour ce que chacun signifie. À propos, présent indique "un état dans lequel Optionnel a une valeur (≈ Pas vide)", et présent indique "un état dans lequel Optionnel n'a pas de valeur (≈ Vide)".

Document

La version Devoxx US 2017 n'est pas encore sortie, mais il semble qu'il ait eu une session avec le même titre lors d'une autre conférence avant cela, et le matériel et la vidéo sont publiés. Cet article, si vous envisagez de démarrer avec Optionnel ou si vous débutez avec Optionnel, contient des informations très utiles à lire.

Famille ouElse facultative

Utilisez les méthodes get () ou Else Family pour récupérer les valeurs contenues dans Optional. La méthode get () lève une exception d'exécution NoSuchElementException lorsque l'objet facultatif est vide, vous ne devez donc pas l'utiliser à moins de vérifier avec isPresent. Normalement, vous utiliserez la méthode de la famille orElse, ou ifPresent (une méthode qui décrit le traitement à effectuer au moment de la présentation dans une expression Lambda).

Cas où vous souhaitez utiliser activement Optional.orElseGet

On en a parlé à TL il y a quelque temps. (Référence: Utilisez orElseGet () pour récupérer la valeur d'Optionnel) Lors de la préparation de la valeur à renvoyer au moment de l'absence par l'appel de méthode, Vous devez utiliser activement orElseGet. Dans ce cas, la méthode est appelée uniquement en cas d'absence.

orElse

Chaque fois que cette ligne est exécutée, les collections.emptyList()Est appelé

.orElse(Collections.emptyList())

orElseGet

Collections uniquement en cas d'absence.emptyList()Est appelé

.orElseGet(Collections::emptyList)

Optional.get() Personnellement, j'ai pensé que "" "ʻOptional.get ()``nie la valeur de Optional et devrait être supprimé." Mais il s'avère que ce n'est pas vraiment si simple. Regardez d'abord le code ci-dessous.

isPresent&get

final Optional<Bounds> caretBoundsOr = editor.getCaretBounds();
if (caretBoundsOr.isPresent()) {
    final Bounds bounds = caretBoundsOr.get();
    return new Point2D(bounds.getMinX(), bounds.getMinY() + 20);
}
return null;

C'est un processus qui suit la règle de "vérifier avec isPresent puis obtenir". En cas d'absence, `return null;` `est le cas où vous voulez vous précipiter dans" Pourquoi utilisez-vous Optionnel si vous retournez null? ".

Alors pourquoi l'avez-vous utilisé?

• L'API de la bibliothèque n'a pas fourni de méthode qui renvoie des valeurs brutes qui ne sont pas facultatives ... J'ai dû utiliser la méthode CodeArea.getCaretBounds de la bibliothèque RichTextFX, qui renvoie facultative.
• La méthode de la famille orElse n'a pas pu être utilisée car la création d'objet a été conçue pour être difficile à appeler pour les utilisateurs de la bibliothèque.

Comme mentionné ci-dessus, la valeur est récupérée après vérification avec isPresent (), elle suit donc les règles de Mr.Marks. Cependant, l'option isPresent-> get est loin d'être meilleure qu'un simple code qui effectue une vérification nulle.

Facultatif est inférieur au code qui ne vérifie que null

1. Facultatif est un objet, créant un objet optionnel supplémentaire qui n'a pas besoin d'être utilisé avec une simple vérification null
2. Le code utilisant Optionnel rend impossible l'exécution d'étapes détaillées dans le débogueur.
3. Facultatif ne peut être utilisé qu'avec Java 8 ou version ultérieure

amendement

Quand j'y pense, est-il prudent d'écrire comme ça ...

final Optional<Point2D> pointOr
        = editor.getCaretBounds()
                .map(bounds -> new Point2D(bounds.getMinX(), bounds.getMinY() + 20));
return pointOr.isPresent() ? pointOr.get() : null;

Optionnel est utilisé avec le filtre (continuez le traitement vers l'opérateur suivant uniquement lorsque la valeur correspond à la condition) et la carte (convertissez la valeur) dans le cas où non seulement le contrôle nul, mais également le traitement suivant sont écrits ensemble. Je pense que c'est mieux.

Cas où l'opérateur ternaire et le contrôle nul sont plus appropriés que l'utilisation facile d'Optionnel

Je pensais que M. Stuart Marks voulait dire que si vous écrivez du code en utilisant Optional comme celui ci-dessous, vous pouvez simplement utiliser l'opérateur ternaire.

Que facultatif.ouElse code

Optional.ofNullable(runScript()).orElse("0").toString()

L'utilisation de l'opérateur ternaire est plus courte, plus facile à comprendre et élimine le besoin d'objets facultatifs inutiles.

Code d'opérateur ternaire pouvant faire de même

final String script = runScript();
script != null ? script : "0"

référence

• (GrepCode) java.util.Optional.java(8u40-b25)