Comportement explicite avec les contrôles par rapport au comportement implicite

Question

Je ne suis pas sûr de savoir comment construire la question, mais je suis curieux de savoir ce que vous pensez des situations suivantes et laquelle préférez-vous.

Nous travaillons sur une application client-serveur avec des winforms. Et nous avons un contrôle qui a des champs calculés automatiquement en remplissant un autre champ. Nous avons donc une devise de champ qui, lorsqu'elle est remplie par l'utilisateur, détermine un remplissage automatique d'un autre champ, peut-être plus de champs.

Lorsque l'utilisateur remplit le champ de devise, un objet Devise est extrait d'un cache en fonction de la chaîne introduite par l'utilisateur. Si la devise entrée n'est pas trouvée dans le cache, une référence nulle est renvoyée par l'objet cache. Plus bas lorsque vous demandez à la couche application de calculer les autres champs en fonction de la devise, une zone spécifique nulle sera renvoyée si vous avez une devise nulle. De cette façon, le comportement implicite par défaut est d'effacer tous les champs. Quel est le comportement attendu. Juste pour le rendre plus clair, quand l'utilisateur entre une "monnaie non disponible" il est averti, bien sûr, mais aussi les champs qui dépendent de la devise entrée devraient être effacés. Cela est effectué en définissant les valeurs de contrôle spécifiques à null. Ce que j'appellerais l'implémentation explicite serait de vérifier que l'objet Currency est null, auquel cas les champs dépendants sont effacés explicitement.

Je pense que cette dernière version est plus claire, moins sujette aux erreurs et plus testable. Mais cela implique une forme de redondance. La version précédente n'est pas aussi claire et implique un certain comportement de la couche application qui n'est pas exprimé dans les tests. Peut-être dans les tests de la couche inférieure, mais quand le besoin se fait sentir de modifier les couches inférieures, de sorte que, compte tenu d'une monnaie nulle, quelque chose d'autre devrait être retourné, je ne pense pas qu'un test qui dit cela sans motivation introduire un bug dans les couches supérieures.

Qu'en pensez-vous?

Answer 1

Explicit est mieux que implicite. - Le Zen de Python, par Tim Peters

Si je comprends bien le tout, avec la manière explicite que vous obtenez la lisibilité avec un peu de redondance, mais je préfère toujours ce sur une obscure, le comportement magique (quelque chose de pas évident sur première vue).

Answer 2

La façon dont je comprends votre question est que vous comparez si vous devez vous fier à NullReferenceException ou à un objet nul pour déterminer l'action suivante.

Voici mes pensées:

1. si vous voulez compter sur exception, l'envelopper dans votre propre exception d'application tels que CurrencyNotFoundException. Les appelants devront vérifier cette exception et se comporter en conséquence. De cette façon, c'est beaucoup plus clair ce qui se passe sous le capot. Si vous pensez que la situation dans laquelle la devise ne se trouve pas dans le cache est fréquente, vous pouvez éviter les exceptions (ce n'est pas une exception par rapport au cas normal). Vous voudrez peut-être opter pour un modèle d'objet nul. Avec le modèle, vous renvoyez un objet NullCurrency. L'appelant peut avoir des stratégies d'affichage correspondantes, et l'une d'elles serait NullCurrencyDisplayStrategy. De cette façon, vous ne devrez jamais compter sur la vérification nulle. L'objet renvoyé est un objet valide dans son domaine métier.

espoir qui aide

Answer 3

D'abord, Dinu Florin est juste, explicite est généralement mieux que implicite (mais la taille ne convient pas à tous, donc il y a des exceptions). Deuxièmement, je ne sais pas si j'ai bien compris votre problème, mais vous pouvez jeter un oeil à la Null-Object Pattern. L'idée est que votre backend doit toujours retourner un objet de données valide (Currency-object dans votre cas), même si aucune donnée n'est disponible. Dans ce cas, un objet Null spécial est renvoyé. Cet objet implémente les mêmes interfaces qu'un objet de données normal, mais il peut contenir des valeurs spéciales pour les champs. Il doit être conçu de telle sorte que votre application n'ait pas à faire la distinction entre un objet de données valide et un objet Null.

Je ne sais pas si cela peut répondre à vos besoins, et cela peut ne pas s'appliquer à votre cas, mais vous devez le faire par vous-même.