Quel est donc le problème avec l'Option?
La question que nous devons relever est la suivante: JDK 8 objets Facultatifs se débarrasser de références nulles? Et la réponse est un grand pas! Ainsi, les détracteurs immédiatement la question de sa valeur en demandant: "alors qu'est-elle bonne pour que l'on ne pouvait déjà le faire par d'autres moyens?
À la différence des langages fonctionnels comme SML o Haskell qui n'a jamais eu la notion de références nulles, en Java on ne peut pas simplement se débarrasser de la des références nulles qui ont historiquement existé. Cela permettra de continuer à exister, et ils ont sans doute leurs usages propres (pour n'en citer un exemple: logique tri-valuée).
Je doute que l'intention de la classe Optionnelle est à remplacer tous les nullable de référence, mais pour aider à la création de plus robuste Api dans laquelle il suffit de lire la signature d'une méthode pour nous dire si nous pouvons nous attendre à une valeur facultative ou non, et forcer le programmeur à utiliser cette valeur en conséquence. Mais en fin de compte, Option sera juste une autre référence, et sous réserve des mêmes faiblesses de toute autre référence dans la langue (ex: vous pouvez retourner une valeur null en Option). Il est bien évident que l'Option n'est pas destiné à sauver la journée.
Comment ces objets facultatifs sont supposées être utilisées ou si elles sont valables ou pas en Java a été le sujet d'un débat houleux dans le projet lambda liste de diffusion. De les détracteurs nous entendre intéressant arguments comme:
- Le fait que d'autres alternatives existent ( c'est à dire IDES comme Ide et IDE Eclipse soutien d'un ensemble de propriétaires annotations pour l'analyse statique de la possibilité de valeur null, la JSR-305 avec des annotations comme @Nullable et @Non null).
- Certains voudraient qu'il soit utilisable que dans le monde fonctionnelle, ce qui n'est pas tout à fait possible en Java puisque la langue ne dispose pas de nombreuses fonctionnalités existantes dans les langages de programmation fonctionnelle comme SML ou Haskell (c'est à dire le pattern matching).
- D'autres soutiennent qu'il est impossible de rénovation préexistante code à utiliser cet idiome (c'est à dire la Liste.get(Object) qui continuera à retourner la valeur null).
- Et certains se plaignent du fait que le manque de support de la langue pour les valeurs facultatives crée un scénario possible en Option qui pourrait être utilisé de façon uniforme dans l'Api, par la création d'incompatibilités, un peu comme ceux que nous aurons avec le reste de l'API Java qui ne peut pas être réparé à utiliser la nouvelle Option de la classe. C'est à peu près à ta question ici. Dans les langues avec support optionnel de type Ceylan, vous n'auriez même pas cette question.
- Un argument irréfutable, c'est que si le programmeur invoque la méthode get dans un objet facultatif, si il est vide, il va soulever une NoSuchElementException, qui est à peu près le même problème que nous avons avec les valeurs null, juste avec une autre exception.
Donc, il semblerait que les avantages de l'Option sont vraiment discutable et sont probablement contraint à l'amélioration de la lisibilité et de l'exécution publique des contrats d'interface.
Je crois que l'adoption de cette Option fonctionnelle idiome est susceptible de rendre notre code plus sûr, moins prompt à null déréférencement des problèmes et de plus en plus robuste et moins sujette aux erreurs. Bien sûr, ce n'est pas une solution parfaite, car, après tout, en Option références peuvent également être à tort, null références, mais je m'attends à ce que les programmeurs en tenir à la convention de ne pas passer des références nulles lorsqu'un objet facultatif est prévu, à peu près comme nous aujourd'hui envisager une bonne pratique de ne pas passer d'une référence null où une collection ou un tableau est prévu, dans ces cas, la bonne est de passer un tableau vide ou de la collection. Le point ici est que nous avons maintenant un mécanisme dans l'API que nous pouvons utiliser pour rendre explicite le fait que pour une référence donnée, nous ne peuvent pas avoir de valeur à affecter à l'utilisateur est forcé, par l'API, pour vérifier que.
Citant Google Goyave de l'article à propos de l'utilisation des objets facultatifs:
"En plus de l'augmentation de la lisibilité qui vient donner un null
nom, le plus grand avantage de l'Option est de son idiot-proof-ness. Il
vous oblige à réfléchir activement sur l'absence de cas si vous voulez que votre
programme à compiler à tous, depuis que vous avez activement déballer le
En option et à l'adresse de cas".
Donc, je crois que c'est à chaque API concepteur de choisir la façon dont beaucoup qu'ils veulent faire dans l'utilisation de l'Option.
