J'ai lu sur de nombreux sites Web Optionnel doit être utilisé comme un type de retour et de ne pas les utilisés dans la méthode des arguments. J'ai du mal à trouver une raison logique. Par exemple, j'ai un morceau de la logique qui a 2 paramètres facultatifs. Donc je pense qu'il serait judicieux d'écrire ma signature de la méthode comme ceci (solution 1):
public int calculateSomething(Optional<String> p1, Optional<BigDecimal> p2 {
// my logic
}
De nombreuses pages web spécifier l'Option ne doit pas être utilisé comme méthode d'arguments. C'est dans cet esprit que je pouvais utiliser la méthode suivante signature et ajouter un clair Javadoc commentaire précisant les arguments peut-être nulle en espérant futurs responsables va lire la javadoc et, par conséquent, effectuer toujours null vérifications avant d'utiliser les arguments (solution 2):
public int calculateSomething(String p1, BigDecimal p2) {
// my logic
}
Sinon je pourrais remplacer ma méthode avec 4 méthodes publiques de fournir une interface plus conviviale et plus évident p1 et p2 sont en option (solution 3):
public int calculateSomething() {
calculateSomething(null, null);
}
public int calculateSomething(String p1) {
calculateSomething(p1, null);
}
public int calculateSomething(BigDecimal p2) {
calculateSomething(null, p2);
}
public int calculateSomething(String p1, BigDecimal p2) {
// my logic
}
Maintenant, j'ai essayer d'écrire le code de la classe qui invoque cette pièce de la logique pour chaque approche. J'ai d'abord récupérer les 2 paramètres d'entrée à partir d'un autre objet qui renvoie options et puis je invoquer calculateSomething. Donc si la solution 1 est utilisé le code d'appel devrait ressembler à ceci:
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1, p2);
si la solution 2 est utilisé le code d'appel devrait ressembler à ceci:
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result = myObject.calculateSomething(p1.orElse(null), p2.orElse(null));
si la solution 3 est utilisé, je pouvais utiliser le code ci-dessus ou que je pouvais utiliser la suite (mais ses une quantité importante plus de code):
Optional<String> p1 = otherObject.getP1();
Optional<BigInteger> p2 = otherObject.getP2();
int result;
if (p1.isPresent()) {
if (p2.isPresent()) {
result = myObject.calculateSomething(p1, p2);
} else {
result = myObject.calculateSomething(p1);
}
} else {
if (p2.isPresent()) {
result = myObject.calculateSomething(p2);
} else {
result = myObject.calculateSomething();
}
}
Donc ma question est pourquoi est-il considéré comme une mauvaise pratique pour utiliser les Options comme des arguments de méthode comme dans la solution 1? Il semble être le plus lisible solution pour moi et le rend plus évident que les paramètres pourraient être vide ou null pour les futurs responsables. (Je suis conscient que les concepteurs de Facultatif destiné à être utilisé uniquement comme un type de retour, mais je ne peux pas trouver toutes les raisons logiques de ne pas l'utiliser dans ce scénario)
