À quelle profondeur faut-il que le journal enregistre?

Question

Pour peindre un scénario, considerer le logic-omitted-Service suivant

public class Service {
   private Validator validator;

   public void submit(Foo foo) {
      if (!validator.isValid(foo)) {
         log.warn("invalid foo");
      } ...
   }
}

public interface Validator {
   boolean isValid(Foo foo);
}

Le problème est que seul le Validor lui-même sait la raison pour laquelle la validation échoue. Je vois seulement deux approches viables pour se concentrer sur cette raison. Soit le Validator

• journalise lui-même la condition d'échec
• retourne un objet complexe contenant une chaîne de caractères raison et un booléen isValid.

La première option est bonne mais laisserait le Service dans l'ignorance de la réelle exécution du journal, et la seconde introduirait une redondance ennuyeuse et une utilisation plus complexe.

Laquelle préférer, ou existe-t-il une meilleure approche?

Answer 1

Vous devez vous poser une question : est-ce que votre client se soucie de la raison de l'échec de la validation ? Et la réponse est : ça dépend. Dans de nombreux cas, vous voudriez informer précisément l'utilisateur final de la cause de l'échec de la validation. Dans ce cas, renvoyez un objet de résultat de validation "complex" (n'utilisez pas d'exceptions ici !), enveloppant essentiellement une collection de chaînes ou de codes (pour permettre i18n). L'objet RésultatValidation serait un objet métier, pas un simple helper de seconde classe.

Dans d'autres situations, vous voulez simplement prendre une décision en fonction de la validité de l'objet ou non. Le code appelant (client) se moque éperdument de la logique interne de la validation. C'est soit valide, soit non. Puis optez pour la méthode directe boolean. Pour des fins de débogage, ajoutez un journalisation à l'intérieur de la méthode de validation. Activez ou désactivez en fonction de votre désir.

Et savez-vous quelle est la meilleure partie ? Vous pouvez avoir deux méthodes et utiliser celle qui convient le mieux au code client. Évidemment, la méthode moins compliquée boolean se contente de déléguer à celle plus compliquée et fournit une vue plus simple :

boolean estValide(Foo foo) {
    valider(foo).estValide();
}

RésultatValidation valider(Foo foo) {
    //journalisation et validation "réelle"
}