settitle - ¿Debo usar Java8/Guava Opcional para cada método que pueda devolver nulo?
set title java (3)
Opcional se usa para representar objetos anulables. Algunos usos de esta clase incluyen
- Como método de devolución, como alternativa a devolver nulo a
indicar que no hay ningún valor disponible - Para distinguir entre "desconocido" (por ejemplo, no presente en un mapa) y "conocido que no tiene valor" (presente en el mapa, con valor
Optional.absent ()) - Para envolver referencias anulables para el almacenamiento en una colección que no admite nulo (aunque hay varios otros enfoques que deben considerarse primero)
Para el primer caso, ¿tengo que devolver Opcional en todos los métodos de devolución que aceptan valores de nulo?
Como observación, creo que uno de los aspectos más importantes que deben tenerse en cuenta al diseñar una aplicación es decidir cómo tratar el "problema nulo". En este sentido, el primer paso sería identificar posibles "fuentes" de nulos. Por ejemplo, la base de datos o las bibliotecas externas utilizadas en el proyecto. El siguiente paso sería "contener" el problema, a saber, para envolver el código problemático (utilizando Opcional) y así bloquear la propagación de nulo en todo el sistema, donde el código desprevenido podría desencadenar NPE.
Para responder a su pregunta, depende ... La mayoría de las veces diría que es innecesario, ya que crea mucho trabajo sin valor (por ejemplo, no usaría opcional para los métodos que llaman a otros métodos privados dentro de las clases, o para métodos que llaman a métodos de clases privadas de paquete), pero el código que existe en el límite fino de diferentes "preocupaciones" (o capas) en su aplicación (la firma de las interfaces / clases que utiliza para consultar el almacén de datos, por ejemplo, o pojos utilizados para "transportar" datos que podrían tener propiedades nulas -DTOs, o, una descripción más general, API publicadas de diferentes módulos- deberían evitar ''pérdidas'' de nulos en otras áreas con preocupaciones diferentes.
Entonces, ¿qué está mal con Opcional?
La pregunta a la que nos enfrentamos es: ¿JDK 8 objetos opcionales eliminará referencias nulas? ¡Y la respuesta es un enfático no! Entonces, los detractores inmediatamente cuestionan su valor preguntando: ¿entonces para qué sirve eso que no podríamos hacer de otra manera?
A diferencia de los lenguajes funcionales como SML o Haskell que nunca tuvieron el concepto de referencias nulas, en Java no podemos simplemente deshacernos de las referencias nulas que históricamente han existido. Esto continuará existiendo, y posiblemente tengan sus propios usos (solo para mencionar un ejemplo: lógica de tres valores ).
Dudo que la intención de la clase Opcional sea reemplazar todas las referencias anulables, sino ayudar a crear API más robustas en las que solo leyendo la firma de un método podamos saber si podemos esperar un valor opcional o no. obligue al programador a usar este valor en consecuencia. Pero, en última instancia, Opcional será solo otra referencia y estará sujeto a las mismas debilidades de cualquier otra referencia en el idioma (por ejemplo, podría devolver un nulo opcional). Es bastante evidente que Opcional no va a salvar el día.
Cómo se supone que se usarán estos objetos opcionales o si son valiosos o no en Java ha sido el tema de un acalorado debate en la lista de correo del proyecto lambda. De los detractores escuchamos argumentos interesantes como:
- El hecho de que existen otras alternativas (por ejemplo, IDES como IntelliJ y Eclipse IDE admiten un conjunto de anotaciones propietarias para el análisis estático de la capacidad de anulación, el JSR-305 con anotaciones como @Nullable y @NonNull).
- Algunos quisieran que fuera utilizable como en el mundo funcional , lo cual no es totalmente posible en Java, ya que el lenguaje carece de muchas características existentes en los lenguajes de programación funcional como SML o Haskell (por ejemplo, la coincidencia de patrones).
- Otros discuten sobre la imposibilidad de actualizar el código preexistente para usar este modismo (por ejemplo, List.get (Object) que continuará devolviendo null).
- Y algunos se quejan del hecho de que la falta de soporte de idiomas para los valores opcionales crea un posible escenario en el que el Opcional podría usarse de manera incoherente en las API, al crear incompatibilidades, muy similares a las que tendremos con el resto de la API de Java. que no se puede retroadaptar para usar la nueva clase opcional. Esta es prácticamente tu pregunta aquí. En idiomas con soporte para tipos opcionales como en Ceylon o como en Kotlin , ni siquiera lo cuestionarías.
- Un argumento convincente es que si el programador invoca el método get en un objeto opcional, si está vacío, generará una NoSuchElementException, que es prácticamente el mismo problema que tenemos con los valores nulos, solo que con una excepción diferente.
Por lo tanto, parece que los beneficios de Opcional son realmente cuestionables y probablemente estén limitados a mejorar la legibilidad y hacer cumplir los contratos de interfaz pública.
Creo que la adopción de este idioma funcional opcional hace que nuestro código sea más seguro, menos rápido para eliminar problemas de eliminación de referencias y, como resultado, es más robusto y menos propenso a errores. Por supuesto, no es una solución perfecta porque, después de todo, las referencias opcionales también se pueden establecer erróneamente en referencias nulas, pero esperaría que los programadores se atengan a la convención de no pasar referencias nulas donde se espera un objeto opcional, casi como hoy consideramos que es una buena práctica no pasar una referencia nula donde se espera una colección o una matriz, en estos casos lo correcto es pasar una matriz o colección vacía. El punto aquí es que ahora tenemos un mecanismo en la API que podemos usar para hacer explícito que para una referencia dada no podemos tener un valor para asignarlo y el usuario es forzado, por la API, a verificar eso.
Citando code.google.com/p/guava-libraries/wiki/… sobre el uso de objetos opcionales:
"Además del aumento en la legibilidad que proviene de dar un nombre nulo, la mayor ventaja de Opcional es su prueba de idiotez. Te obliga a pensar activamente sobre el caso ausente si deseas que tu programa compile en absoluto, ya que tienes que desenvolver activamente el Opcional y abordar ese caso ".
Entonces, supongo que depende de cada diseñador de API elegir hasta dónde quieren llegar en el uso de Opcional.
Algunos desarrolladores influyentes como Stephen Colebourne y Brian Goetz han publicado algunos artículos interesantes más recientemente sobre el uso adecuado de opcionales. Particularmente encontré útil lo siguiente:
- Debería Java Getters Return Optional
- Java SE 8 Opcional, un enfoque pragmático
Comparado con Guava, un problema molesto con java.util.Optional es que no proporciona un método como
orElse(Optional<T>): Optional<T>
que, por otro lado, se define en com.google.common.base.Optional como
or(Optional<T>): Optional<T>
La falta de esta característica específica limita las aplicaciones monádicas de Java 8''s Optional.
ACTUALIZAR:
Guava or(Optional<T>) se puede replicar como en Java 8 opcional como
optionalA.map(Optional::of).orElse(optionalB)
o
optionalA.map(Optional::of).orElseGet(() -> computeOptionalB)
ACTUALIZAR:
En Java 9 (¡finalmente!) Podrá usar Optional.or(Supplier<Optional<T>>) :
optionalA.or(() -> computeOptionalB)
¡Está muy bien!