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.
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
Sí. Ver mi edición – Mau