¿Por qué no se utiliza opcional para las variables de instancia?

Miguel :

He estado leyendo mucho sobre los casos en los que Optionalse deben utilizar.

Muchas de las páginas que he leído dicen que Optionalno deben ser utilizados para las variables de instancia privada y en su lugar debe ser devuelto por captadores.

Yo habría pensado que tener variables de instancia privadas como opcional seguiría siendo útil. Si alguien mira a mi código pueden ver que un valor puede estar vacío, en lugar de tener que comprobar la documentación para ver si podía ser devuelto nulo.

En Scala nula nunca se usa y sólo está realmente allí para la interoperabilidad con Java. Se recomienda utilizar siempre una opción si un valor puede ser nulo. Este enfoque tiene mucho más sentido para mí.

Aquí hay una página que mencionar:

https://blog.joda.org/2015/08/java-se-8-optional-pragmatic-approach.html

Aquí está el código de ejemplo.

private final String addressLine;  // never null
private final String city;         // never null
private final String postcode;     // optional, thus may be null

// normal getters
public String getAddressLine() { return addressLine; }
public String getCity() { return city; }

// special getter for optional field
public Optional<String> getPostcode() {
  return Optional.ofNullable(postcode);
}

La única ventaja que veo es que si desea realizar una serie objeto ahora es posible, ya que no es el almacenamiento opcional en una variable.

La desventaja es que usted no sabe el código postal podría ser nula hasta que se comprueba el tipo de retorno del captador. Si fueras nuevo en el código que podría perder este complemento extender la clase, haciendo una excepción de puntero nulo.

He aquí una pregunta sobre Scala de Option.

Cuándo usar Opción

¿Por qué hay una diferencia entre Java y Scala con la forma opcional se debe usar?

Krzysztof Atłasik:

No todos los desarrolladores de Java siquiera están de acuerdo con el enfoque que ha descrito. Por favor revise esta entrada por el creador de Lombok.

Supongo que la razón de un enfoque diferente de utilizar Optionalen Java es que la comunidad de Java vivió sin él hasta el 8 de Java, por lo que la mayoría de la gente se utilizaron para nula . En un lado una gran cantidad de nuevas APIs (como findAnydesde Stream) de retorno Optional, pero sigue siendo una gran cantidad de métodos de biblioteca estándar acaba de regresar nula , por lo que siempre tiene que recordar, ya sea para envolver sus llamadas a funciones con Optional.ofNullableo comprobar si el valor no es nulo.

Optionalse agregó a Java 8 pero no se recomienda utilizarlo como campos de clase, ya Optionalque no aplica Serializable(y la serialización de Java se utiliza como motor de serialización por defecto por muchos marcos o sistemas como Akka, Spark, Kafka, etc.).

Por otro lado Optionestá muy fuertemente unido con la biblioteca estándar Scala. Por lo que yo sé, las API de la biblioteca estándar de Scala sin retorno nula , pero Option, y no se recomienda para uso nulo en absoluto en su código Scala. Incluso puede configurar su proyecto de que se producirá un error al compilar si nula se utiliza .

Optiones también Serializabley su práctica normal de uso es como campos de la clase de valores que puede estar vacío.

Si desea utilizar un enfoque similar en su código Java compruebe la opción de Vavr . Es serializable, para que pueda ser utilizado con seguridad como campos y también tiene dos subclases Noney Some(de manera similar como de Scala Option), para que pueda ser utilizado en concordancia con el modelo de Vavr:

Match(option).of(
    Case($Some($()), "defined"),
    Case($None(), "empty")
);