Es aceptar objeto como un parámetro aceptable?

Question

Vamos a decir que tengo un cuadro de texto o cualquier otra forma de entrada que pide un número de la seguridad social. Quiero señalar que el SSN es un ejemplo puro Simplemente pensé de a partir de ahora. Esta entrada, naturalmente, ser almacenado como una cadena inicialmente.

string s = Console.ReadLine();

Digamos que quiero tener un método que valida un SSN y podría ser utilizado a lo largo de mi código en todo tipo de lugares. Heck, que incluso podría llamar al método sobre una variable que no ha sido determinado por la entrada de usuario.

Es esto aceptable?

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

O le chico insistir que pido un tipo de datos específico, por ejemplo

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

y por lo tanto se me requiere para convertir la entrada del tipo de datos correcta antes de llamar al método en él.

Por cierto: No estoy pidiendo cómo hacer un código IsValidSSN adecuado :) Sólo quería dar un ejemplo de lo que me refería cuando dije: ¿Puedo aceptar el tipo de datos de objeto como un parámetro o debería tratar de evitarlo?

Answer 1

Si debe aceptar un objeto que al menos tendría sobrecargas del método que toman parámetros inflexible. Luego hacer que las variantes de objeto alimentar en estos métodos.

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

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

Answer 2

Depende completamente de su diseño y al que desea que se produzca la validación. Realmente depende fundamentalmente de la arquitectura general y su jerarquía de clases. No es malo hacerlo de cualquier manera; sólo asegúrese de que es la forma en que se ajusta a su diseño arquitectónico.

Answer 3

No veo ningún valor en la aceptación de un objeto en este caso. Piense en cómo se espera que la función de trabajar. (Es evidente que no es así, ya que el código que envió no funciona). Creo que está planeando algo como esto:

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

¿Cómo es mejor 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)); }

Los métodos sobrecargados son más simples y más rápido, ya que más de la decisión sobre qué hacer a partir de tiempo de ejecución a tiempo de compilación.

Answer 4

En el ejemplo anterior es mucho más fácil crear una IsValidSSN mecanografiado. En general me parece que la tipificación reduce los errores y flexibilidad.

En circunstancias en las que la flexibilidad si se suma a continuación, utilizando objeto es probablemente la mejor opción, pero se espera que para hacer frente a algunas excepciones fundido choque en los registros.

Para todos los demás casos ser estricto con su escritura, o escribirlo en pitón.

Answer 5

En lo personal, me gustaría hacer una clase de SSN y podrá solicitar que el SSN si era válido o no. Es importante tener clases que representan los directores en su lógica de negocio. Esto es en gran medida, por ejemplo, lo que podría hacer con algo que requiere más validación como una clase de tarjeta de crédito. Entrega alrededor de los objetos no es la mejor si se puede evitar y entrega en torno a algo que es un director en su lógica de negocio como una primitiva es demasiado malo (su arquitectura hace SSN1 + SSN2 = SSN3 perfectamente válido, a pesar de que en la lógica de negocio, es absurdo ).

Answer 6

En este caso, yo diría que era inaceptable. ¿Qué pasa si la entrada tiene guiones, o algún otro carácter de separación (por ejemplo: ### - ## - ####)? Es obvio que no sería capaz de analizar el valor como un entero, pero el valor seguiría siendo válida. ¿Cómo sobre el uso de una expresión regular en su lugar para asegurar el valor es lo que ha deseado.

En términos de uso de la "objeto" tipo como un parámetro, esto es completamente válida en muchos casos. De hecho, se utiliza en todo el .NET Framework (mirar a los delegados de eventos):

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

Esto sería un simple caso de boxeo / unboxing, que era realmente la única manera de llevar a cabo operaciones de "genérico" sobre las variables hasta .NET 2.0.

También puede utilizar genéricos para resolver este problema sin necesidad de fundición. Si crea una interfaz que implementa algo así como INumeric (no sé si esa es la interfaz real) o IComparable usted debería ser capaz de realizar la operación de una manera más elegante:

bool público IsValidSNN (INumeric SSN) {}