Discussion :

[Yonito]

Salut tous le monde,

Je suis entrain de terminer le livre Java 8 in action, qui decrit toutes les evolutions de la derniere version de java.

Un des derniers chapitre concerne le moyen d eviter les "if(object != null)" qui sont parfois en abondance ou d eviter les nullPointerException en utilisant Optional.

Selon le livre, il est plus interessant de renvoyer un object Optional plutot que null.

Il donne un exemple de code review d un ancien code utilisant des null et propose de remplacer les variables de classe qui sont susceptible d etre null par Optional.

Si une classe Car possede une instance Insurance alors cette variable sera declaree et initialise dans un constructeur par exemple ainsi :

Optional<Insurance> insurance = Optional.ofNullable(insurance)

de telle maniere a pouvoir utiliser la methode isPresent() de l object Optional pour eviter le if != null


Ma question est la suivante : Que pensez vous de cette nouvelle approche ?
Personnellement, je ne me voit pas utiliser/modifier une classe qui possederait beaucoup de variable pouvant etre null par un Optional. J ai l impression que cela rend le code tres lourd. Si je puis dire on s est habitue au traditionel if != null qui n est pour moi pas si affreux que cela.
Je pense utiliser plus souvent Optional dans des cas bien precis comme par exemple la valeur retour d une methode mais cela n irait pas plus loin que cela.

Bref, j aimerai avoir l avis des experts et des moins experts

merci

[Gugelhupf]

Salut,

Optional<T> est une alternative à l'opérateur coalesce présent dans d'autres langages (ex : C#). Comme tu as pu le remarquer utiliser Optional<T> peut éviter les NullPointerException si on l'utilise comme valeur de retour pour faire du "function chaining" mais n'est pas conviviale si on l'utilise comme attribut ou paramètre de méthode.

propose de remplacer les variables de classe qui sont susceptible d etre null par Optional

Brian Goetz* dit (source) :

You should almost never use it as a field of something or a method parameter.

En ce qui me concerne je n'utilise pas Optional<T>, c'est le genre de feature Java 8 qu'on peut surexploiter (parce que c'est "hype") mais qui peut nuire au code si on l'utilise mal, et puis comme tu dis mis à part quelques cas très particuliers le fait de tester null c'est pas si mal.

Tu as un article Oracle concernant ce sujet : lien.
* Brian Goetz est un architecte du langage Java chez Oracle.

[tchize_]

mis à part quelques cas très particuliers le fait de tester null c'est pas si mal.

J'attends avec impatience de trouver quelqu'un qui écrit ce type de code:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
Optional<Xyz> result = monAppel();
if (result == null)
  //...
if (result.isPresent())
  //...
else
  //...

[Yonito]

Salut tous le monde,

Donc en gros, ne pas utiliser ce principe a tout bout de champs. On est donc bien d'accord que sur un retour de methode cela suffira amplement et n'alourdira pas le code

[Gugelhupf]

En théorie oui, mais tu sais à mon avis ils ont surtout créé ce type pour le function chaining dans l'API Stream (Java 8).

[bouye]

En même temps il s'agit d'une règle de bonne conduite a suivre : si une méthode renvoie un Optional ou prend en paramètre un Optional, cette valeur ne doit jamais être null, elle ne peut que soit contenir qq chose, soit etre Optional.empty(). Même chose pour un membre dans une classe.

Évidement le langage ne supporte toujours pas d'outil permettant de forcer cette règle (au hasard la présence d'une annotation @NonNull ou un check forcé du code par compilateur / de l'IDE sur les usages du type Optional), donc après, on est pas a l'abri d'un programmeur pas doué ou d'une lib tierce implémentée comme ses pieds.