2017-04-26 6 views
2

J'utilise actuellement la bibliothèque Immuable pour générer objet JSON de mon application Web.Pourquoi nul immuable est découragé?

Regarder this chapitre, la première ligne dit:

L'utilisation d'attributs nullables est déconseillée.

Ma question est:

1) pourquoi? Quel est le problème avec un objet nul?

2) si je suis en utilisant une enveloppe d'objet thirdy et je ne sais pas si l'article est nul ou non, donc en utilisant le code constructeur de classage échouera:

MyImmutableWrapperObject 
    .builder(). 
    .mobile(input.getMobile()) // don't know if null or not 
    .build(); 

Y at-il optimal Solution?

EDIT:

@JsonProperty("mobile") 
public abstract Optional<String> mobile(); 

... 

// composing builder 
if (input.getMobile() != null) 
     builder.mobile(input.getMobile()); 

Le produit est JSON:

"mobile": { 
    "present": false 
}, 

Comment puis-je supprimer complètement les champs vides?

J'ai lu this, mais il utilise gson.toJson qui renvoie un objet String qui n'est pas mon chemin souhaitable.

extérieurs post:

Je viens de découvrir que en option ne montre pas de valeur réelle, même si elle est présente, mais il n'affiche que la vraie/fausse valeur, donc je ne ont pas besoin.

Répondre

6

C'est exactement le point OMI, vous ne savez pas si un objet est nul ou non; Donc, lorsque vous l'utiliserez plus tard, vous pourriez évidemment obtenir un NullPointerException. En utilisant une bibliothèque qui l'interdit, vous ne vous soucierez pas si quelque chose est nul ou non nul (car il ne sera pas nul), donc moins de code et moins de if -statements qui polluent le code avec des vérifications nulles potentielles.

ayant également une référence null pourrait signifier des choses différentes dans des contextes différents. Par exemple, je l'ai vu du code qui a besoin de trois états pour un Boolean: true, false et pas encore fixé (comme null). Je trouve cela faux, mais encore parfois le voir.

C'est la raison pour laquelle Optional a été introduit dans goyave et est maintenant dans le JDK. Cela force l'utilisateur à faire quelque chose avec un Optional. Par exemple:

Optional<Integer> i... 

    if(i.isPresent()).... // you are forced to do this check 

Eh bien vous pouvez faire évidemment:

i.get() 

mais cette méthode est documentée qu'il pourrait se briser.

même est tout simplement pas vrai pour une référence:

Integer i = null; 
if(i == null) // this is not an operation that is mandatory 

L'article pari que j'ai vu/lu à ce jour sur ce sujet est Guava explanation

+0

donc un moyen possibile pourrait être aussi: Builder builder = ImmutableAccount \t \t \t \t .builder() if (entrée.getMobile()! = null) builder.mobile (entrée.getMobile()); return builder.build() –

+1

@FabrizioStellato il pourrait être - oui. Il pourrait être juste dans votre cas de stocker un 'Optional.empty()' dans ce cas. Ou même pour le constructeur de faire quelque chose avec ce null à la place - cela dépend. – Eugene

+0

Voir ma question EDITED –