J'ai une fonction C # qui fait du traitement et doit renvoyer des chiffres sur ce qu'il a traité, succès, échec, etc.
Quelqu'un peut-il me dire s'il existe des classes de structure standard qui géreront ceci (par exemple, nombre d'enregistrements traités, nombre réussi, échec, etc.)?
Alternativement, quelqu'un peut-il dire comment ils gèrent habituellement cela? Est le meilleur moyen de créer une classe ou d'utiliser des paramètres?
6 Réponses :
Je ne pense pas qu'il y ait de classes intégrées pour cela. Habituellement, je créerai ma propre classe pour accueillir le type de résultat dont vous parliez, et oui, je préfère une classe de résultat au lieu de paramètres simplement parce que je sens qu'il est plus propre et que je ne suis pas obligé de préparer des variables et de taper le paramètres chaque fois que je dois appeler cette fonction.
Je ne pense pas qu'il y ait quelque chose de standard qui le fera pour vous.
Un excellent exemple d'utilisation des paramètres out>, est le Tryparse Fonctions.
Je pense que la trypairse est dans la manière dont il est simplement d'être compatible en arrière. En supposant si la nullable était déjà là quand ils ont créé une trypairse, ils préféreraient (au moins je le ferai) de retourner nullable
Je ne pense pas qu'il y ait une classe standard pour représentant ce type d'information. La meilleure façon de gérer cela est probablement de définir votre propre classe. Dans C # 3.0, vous pouvez utiliser des propriétés mises en œuvre automatiquement, ce qui réduit la quantité de code que vous devez écrire:
class Results {
public double Sum { get; set; }
public double Count { get; set; }
}
"Ne vaut pas la peine de déclarer une nouvelle classe pour tenir les résultats"? Ah bon?
Je n'utiliserais pas tuple <..> dans les membres publics de la classe. Dans un membre privé qui peut être utilisé uniquement à partir d'un nombre limité d'endroits, il peut être plus facile de l'utiliser plutôt que de construire une classe unique.
Hmm, ok, chacun à eux-mêmes. Pour 6 lignes de code, je créerais une classe d'enfants privée juste pour plus de clarté, mais cela ne veut pas réclamer la supériorité, je viens de ressentir de ce méchant écoutant lorsque j'utilise une classe pour autre chose que le but recherché.
Je vois que cela est répertorié comme l'un des usages communs de Tuple ici ( MSDN.MicRosoft .Com / fr-US / Bibliothèque / DD268536.aspx ) Assez juste. Le nom tuple pour moi implique l'un des deux premiers fins énumérées.
@PDR: Comme tout, cela dépend des préférences personnelles et du type de projet et de la phase actuelle du projet. Par exemple, les tuples sont parfaits pour le prototypage.
+1 pour les propriétés de tuple et mis en œuvre automatiquement. Cependant, j'aurais aussi recommandé des types anonymes.
@Venemo: Les types anonymes ne fonctionnent pas bien si vous devez retourner quelque chose à la suite d'une méthode (non générique), car elles ne peuvent être utilisées que localement.
Si vous avez deux valeurs à revenir, utilisez-en une comme valeur de retour et un en tant que paramètre out>.
Si vous en avez plus, créez votre propre classe de valeur de retour et renvoyez cela.
Je peux être d'accord avec cela si le scénario d'utilisation, d'une certaine manière, sentit juste juste, comme la méthode Tryparse. Mais cela se sentira bizarre si la valeur de retour est une INT représentant l'âge de la personne où le nom de la personne est renvoyé via un paramètre String Out. C'est comme si les valeurs sont liées au contextuel, mais déconnectées de la manière dont ils sont retournés à l'appelant.
Je ne sais pas s'il y a un cadre connu pour le faire, mais c'est une pratique courante dans tous les nouveaux projets que je suis impliqué maintenant.
On dirait une bonne pratique pour avoir une classe de résultat personnalisée dans afin de donner à la méthode exécutante les résultats appropriés et / ou de l'objet de résultat. p>
CLASSE GENERIC SIMPLE SIMPLE: FORT> P> var result = CanDivideNumber(1, 0);
// Was the operation a success?
// result.Success
// Need to get error details?
// result.Errors
// The processing result?
// result.Value
11 ans plus tard, je peux dire que c'est de mieux adopter le modèle de résultat avec une classe de résultat si vous allez cette route. Utilisation de TUPLE Maintenant, vous entrez toujours dans TÂCHE Tâche