Type de retour de méthode

Question

Dans mon entreprise, un système est conçu pour avoir 3 couches. Layer1 est responsable du traitement de la logique métier. Layer3 appelle les systèmes d'extrémité. Layer2 se trouve entre les deux couches de sorte que layer1 n'a pas besoin de connaître les systèmes dorsaux. Pour relayer les informations de layer3, layer2 doit définir l'interface avec layer1. Par exemple, layer1 veut vérifier si un code PIN de l'utilisateur est correct. Il appelle la méthode layer2 checkPin(), puis layer2 appelle le système back-end approprié. Les résultats checkPin() peuvent être: correctPin, inCorrectPin et internalError. À l'heure actuelle, nous avons défini le type de retour 'int'. Donc, si layer2 renvoie 0, cela signifie correctPin; si 1 est retourné, cela signifie inCorrectPin; Si 9 est retourné, cela signifie internalError.

Cela fonctionne. Cependant, je me sens un peu mal à l'aise avec cette approche. Y a-t-il de meilleurs moyens de le faire? Par exemple définir un enum CheckPinResult {CORRECT_PIN, INCORRECT_PIN, INTERNAL_ERROR}, et le type de retour CheckPinResult?

Merci, Sarah

Answer 1

J'aime l'approche enum. C'est auto-documenté et facilement extensible. Vous pouvez définir la valeur renvoyée par chacun pour correspondre à la convention 0, 1, 9 que vous avez en place. Lancer une exception est certainement une approche défendable, mais jeter des exceptions peut être une chose coûteuse. J'ai toujours cru qu'ils devaient être utilisés pour indiquer des situations vraiment exceptionnelles. Avoir une mauvaise épingle peut ou ne pas être aussi exceptionnel en fonction de votre problème d'affaires. Si votre processus permet une fiabilité de «cinq neuf» pour les épingles, alors je dirais qu'une exception serait un bon moyen d'aller.

Mais si les taux d'échec sont plus de l'ordre de 1%, je dirais qu'une valeur de retour pourrait être meilleure. Vous voudrez peut-être faire défiler un grand nombre de valeurs et simplement accumuler les numéros de pièce avec les broches défectueuses en tant que gros lot. Cela dépend de la façon dont vous utilisez le code d'erreur.

Answer 2

Est-ce un cas commun raisonnable que vous obtenez l'erreur interne? Sinon, j'aurais checkPin retourner un booléen et lancer une exception s'il y a une erreur interne (mais j'appellerais probablement la méthode pinIsValid ou quelque chose comme ça à la place). Si cela (pour une raison quelconque) est un résultat attendu de rencontrer l'erreur interne, alors un enum à trois états pourrait probablement bien fonctionner (j'ai un cas similaire dans mon projet actuel).

Answer 3

Enum est certainement une amélioration par rapport aux types de retour entiers et une approche parfaitement valide. Une autre option serait d'avoir une signature couche 2 tels que:

public boolean isPINValid() throws InternalErrorException(); 

Depuis, je présume, les erreurs internes sont l'exception, pourquoi ne pas les traiter en tant que telle?

Answer 4

Ceci est une question de style. La façon dont vous avez décrit est une sorte de style C pour atteindre l'objectif. Le style java est le suivant: checkPin (pin) devrait renvoyer un booléen. Vraie signifiant que l'épingle est correcte et fausse ce qui signifie que ce n'est pas correct. Si une erreur survient, vous lancez une exception. Les exceptions sont la manière standard de traiter les erreurs dans Java. Les exceptions sont utiles car elles peuvent contenir des types et des messages d'erreur pour faciliter le débogage. Je dis que le mécanisme que vous décrivez est un style C car en C la manière standard de gérer les erreurs est de renvoyer un entier qui mappe à une définition puis de transmettre par référence la valeur que vous recherchez (dans ce cas-ci) cas un booléen).Donc, c vous auriez

int checkPin(int pin, bool &ans); //returns an error value. 

De toute façon, je vous recommande fortement de ne pas retourner la valeur d'erreur au même endroit que vous retourniez le booléen. Cela crée de la confusion car une seule valeur (la valeur de retour) ne devrait vraiment représenter qu'une seule chose. Le statut de l'erreur et la réponse à la question sont deux choses différentes et doivent donc être renvoyés par des canaux différents.

J'espère que cela a aidé.