Accepte l'objet en tant que paramètre acceptable?

Question

Disons que j'ai une zone de texte ou toute autre forme d'entrée qui demande un numéro de sécurité sociale. Je ne veux noter que le SSN est un pur exemple, je pensais simplement comme en ce moment. Cette entrée sera naturellement stockée sous forme de chaîne au départ.

string s = Console.ReadLine();

Disons que je veux avoir une méthode qui valide un et il pourrait SSN être utilisé tout au long de mon code dans toutes sortes d'endroits. Zut, je pourrais même appeler la méthode sur une variable qui n'a pas été déterminée par l'entrée utilisateur.

Est-ce acceptable?

public bool IsValidSSN(Object SSN)
{
int mySSN;
    if(Int.Parse(SSN == false)
    {
    mySSN = Convert.toInt32(SSN);
    }
...
}

Ou voulez-vous gars insister que je demande un type de données spécifique, par exemple

public bool IsValidSSN(int SSN)
{
...
}

et à cet effet, je suis obligé de convertir l'entrée du type de données correct avant d'appeler la méthode là-dessus.

BTW: Je ne demande pas comment faire un code IsValidSSN bon :) Je voulais juste donner un exemple de ce que je voulais dire quand je l'ai dit: Puis-je accepter le type de données objet comme paramètre ou devrais-je essayer de l'éviter?

Answer 1

Si vous devez accepter un objet que je aurais au moins surcharges de la méthode qui prennent des paramètres fortement typés. Ensuite, ont les variantes d'objet alimenteront ces méthodes.

public bool IsValidSSN(object ssn) {
  ...
  IsValidSSN(Convert.ToInt32(ssn));
  ...
}

public bool IsValidSSN(int ssn) {
  ...
}

Answer 2

Il dépend entièrement de votre conception et où vous voulez que votre validation se produise. Cela dépend vraiment fondamentalement de votre architecture globale et votre hiérarchie de classes. Il n'a pas tort de le faire de toute façon; juste être sûr que c'est la façon qui correspond à votre conception architecturale.

Answer 3

Je ne vois aucune valeur à accepter un objet dans ce cas. Pensez à la façon dont vous vous attendez à cette fonction de travail. (Il est clair que vous n'avez pas, puisque le code affiché ne fonctionne pas). Je pense que vous avez l'intention de quelque chose comme ceci:

if (SSN is string)
    SSN = Convert.toInt32(SSN);
else if (SSN is TextBox)
    SSN = Convert.toInt32(SSN.Value);
else /* etc */

Comment est-ce mieux que:

 bool isValidSSN(int SSN) { /* real valuation code */ }
 bool IsValidSSN(String SSN)  { return isValidSSN(Convert.toInt32(SSN)); }
 bool IsValidSSN(TextBox SSN)  { return isValidSSN(Convert.toInt32(SSN.Value)); }

Les méthodes surchargées sont plus simples et plus rapides, car ils plus la décision sur ce qu'il faut faire de l'exécution de la compilation.

Answer 4

Dans votre exemple ci-dessus, il est beaucoup plus facile de créer un IsValidSSN typé. En général, je trouve que le typage réduit les bugs et la flexibilité.

Dans des circonstances où la flexibilité si primordiale puis à l'aide d'objets est probablement le meilleur choix, mais attendez-vous à faire face à quelques exceptions près clash coulé dans les journaux.

Pour tous les autres cas, être stricte avec votre saisie, ou l'écrire en python.

Answer 5

Personnellement, je fais une classe et être en mesure SSN demander que si elle était SSN valide ou non. Il est important d'avoir des classes qui représentent les directeurs dans votre logique métier. Ceci est très bien, par exemple, ce que vous pourriez faire quelque chose qui nécessite une validation plus comme une classe de carte de crédit. Remise autour d'objets est pas le meilleur si vous pouvez l'éviter et la remise autour de quelque chose qui est un principal dans votre logique métier comme primitive est mauvais aussi (votre architecture fait SSN1 + SSN2 = SSN3 parfaitement valable, même si, dans la logique métier, il est un non-sens ).

Answer 6

Dans ce cas, je dirais qu'il était inacceptable. Que faire si l'entrée a des traits, ou un autre caractère de séparation (par exemple: ### - ## - ####)? Manifestement, vous ne seriez pas en mesure d'analyser la valeur comme un entier, mais la valeur serait encore valide. Que diriez-vous en utilisant une expression régulière au lieu d'assurer la valeur est ce que vous avez désiré.

En ce qui concerne l'utilisation du type « objet » en tant que paramètre, cela est tout à fait valable dans de nombreux cas. En fait, il est utilisé dans le .NET Framework (regardez les délégués de l'événement):

public void Control_MouseOver(object sender, MouseEventArgs e){}

Ce serait un cas simple de boxe / unboxing, ce qui était vraiment la seule façon d'effectuer des opérations « génériques » sur les variables jusqu'à .NET 2.0.

Vous pouvez également utiliser Génériques pour résoudre ce problème sans qu'il soit nécessaire pour la coulée. Si vous créez une interface qui implémente quelque chose comme INumeric (je ne sais pas si c'est l'interface réelle) ou IComparable vous devriez être en mesure d'effectuer l'opération d'une façon plus élégante:

publique bool IsValidSNN (INumeric NSS) {}