2010-07-14 39 views
5

A menudo tengo jerarquías de llamadas porque todos los métodos necesitan los mismos parámetros. Si no quiero ponerlos en el nivel de instancia (miembro de la clase), entonces siempre me pregunto si es importante verificar la validez de los mismos en cada método.Revisiones repetidas de parámetros en las funciones

Por ejemplo:

public void MethodA(object o){ 
    if(null == o){ 
     throw new ArgumentNullException("o"); 
    } 
    // Do some thing unrelated to o 

    MethodB(o); 

    // Do some thing unrelated to o 

} 

public void MethodB(object o){ 
    if(null == o){ 
     throw new ArgumentNullException("o"); 
    } 
    // Do something with o 
} 

Si Method A utiliza el parámetro, entonces es claro, tiene que comprobar la validez allí y también en MethdoB. Pero mientras MethodA no haga nada más con o que darle a MethodB, es una buena práctica verificar la validez también en MethodA.

La ventaja de marcar también en MethodA puede ser que la excepción arroja el método que ha llamado el llamado, eso es bueno, pero ¿es necesario? La pila de llamadas indicará esto también. Tal vez es significativo en público, interno, protegido pero no en métodos privados?

Tomé la verificación nula como ejemplo, pero también las validaciones de índice o las validaciones de rango caen en la autoevaluación, sin embargo, creo que existen limitaciones debido al peligro de código redundante. ¿Qué piensas?

ACTUALIZACIÓN

A través de la respuesta de AakashM he visto que estaba a poco precisa. MethodA no solo llama al MethodB, sino que también hace otras cosas pero no está relacionado con o. Agregué un ejemplo para aclarar esto. Gracias AakashM.

Respuesta

9

Código de Steve McConnell Se habla completamente sobre el concepto de 'la barricada' - un muro defensivo fuera del cual no se confía en los datos y dentro del cual se confía en los datos. Los datos que quieran ingresar a la barricada deben pasar por un proceso de validación, pero dentro de la barricada, los datos se pueden mover sin restricciones mediante el código de validación.

Si puede imponer esta cantidad de estructuración y estratificación en su proyecto, y mantenerlo, hace que el código dentro de la barricada tenga menos ceremonia y más esencia. Pero solo se necesita un método para llamar a la barricada para que todo salga mal.

En su ejemplo, MethodB es public. Esto significa que no tiene garantías futuras automáticas de que MethodA sea su único interlocutor; por lo tanto, le diría que su código de validación debe permanecer. Si fuera private para la clase, sin embargo, podría hacer un argumento para eliminarlo.

En cuanto a MethodA, si es lo que realmente hace nada más de llamada MethodB, no debería existir. Si es un apéndice para una expansión futura, y en algún momento va a hacer algo con o, entonces su código de validación también debería permanecer.

1

Creo que debe asegurarse una vez que se produce el valor de entrada (responsabilidad de la persona que llama). Esto funciona si la clase es utilizada solo por clientes internos. Si es parte de la API pública, entonces no puede sacar cheques, pero es posible que desee factorizarlos, como se sugiere en otras respuestas.

Para realizar pruebas, también puede usar Debug.Assert(o != null) en ambos métodos y las comprobaciones se eliminarán del código de publicación, si el rendimiento es un problema.

+0

Donde se produce el valor de entrada - ¿significa esto para la persona que llama? El ejemplo que tuve en mente al escribir mi ejemplo fue que los métodos A y B son accesibles desde el exterior de la clase y es legítimo llamar a uno de los dos (MethodA hace lo mismo más un poco más que MethodB) – HCL

+0

Sí. Ver mi edición – Mau

1

No considero la verificación de parámetros "código redundante". Debe proteger todos los puntos de entrada externos. Si tiene un método private, de modo que sepa, para cuando llegue el flujo, que todos sus parámetros serán válidos, entonces quizás tenga un caso, pero para los métodos public (e incluso protected), realmente no es así.

Cuestiones relacionadas