¿Cambiar el nombre solo por nulo?

Question

Trabajo en el desarrollo de una API externa. He añadido un método para mi interfaz pública:

public void AddMode(TypeA mode); 
public void AddMode(TypeB mode); // the new method, TypeB and TypeA are not related at all 

Se veía bien, hasta que una prueba se supo que estaba pasando un null. Eso confundió al compilador con una llamada ambigua. Arreglé la prueba arrojando el nulo.

Sin embargo, mi pregunta es:

• ¿Debo cambiar el nombre sólo a causa de esto?
• ¿O debería dejar que el cliente haga el reparto como lo hice yo? (si pasan nulo por cualquier razón)

¿Cuál es el mejor en este caso al diseñar las API?

Editar:

la llamada era así AddMode (nulo), no me gustan:

TypeA vl = null; 
AddMode(v1); // this doesn't cause a problem 

Answer 1

Una API debe diseñarse de modo que sea fácil de usar correctamente y difícil de usar de forma incorrecta. Su API es fácil de usar correctamente:

AddMode(new TypeA()); 

se compila.

Es más difícil de usar de forma incorrecta:

AddMode(null); 

no compila. El usuario está obligado a hacer algo como

AddMode((TypeA)null); 

Lo que debería hacerle pensar, si este es el uso esperado. Así que creo que tu API está bien tal como está.

Answer 2

Creo que eso depende de lo excepcional null como un valor para el argumento correspondiente es .

Comparar, por ejemplo, this ArgumentNullException constructor: Se llama con más frecuencia cuando se debe establecer una excepción interna. De lo contrario, se pasa this constructor, que exceptúa el nombre del argumento ilegal. En ocasiones raras, el primero debe invocarse porque se debe suministrar un mensaje personalizado, pero no se proporciona ninguna excepción interna (normalmente hago esto cuando estoy lanzando la excepción para un argumento de matriz/colección que contiene null, pero no es null en sí). Entonces, en este caso, necesito el lanzamiento explícito, y diría que es aceptable allí.

Si sus métodos realmente hacen lo mismo, pero null sigue siendo un valor habitual, es posible que desee agregar una sobrecarga sin parámetros para la variante null (es decir, la conversión explícita todavía es posible, pero los usuarios también puede llamar a la sobrecarga sin parámetros vez)

Si sus métodos de hacer algo un poco diferente, y sin embargo, algo más para null, se puede pensar en no permitir null completo para los métodos que has demostrado y la adición de una sobrecarga sin parámetros para el caso null.

Actualización: Si null no es aceptable de todos modos (y dará lugar a una excepción), entonces debe dejar el método tal como está. Con excepción de los propósitos de prueba, nunca debe haber ninguna situación en la que se pase al método literal null, ya que esto invariablemente producirá una excepción. Por lo tanto, no cambie sus nombres de sobrecarga en este caso.

Answer 3

¿Es nula la entrada válida para este método de todos modos?

Personalmente, lo dejaría como está siempre y cuando ambas sobrecargas estén relacionadas con AddMode, ya que es de esperar que AddMode (X) y AddMode (Y) estén haciendo algo relacionado entre sí.

Si no están relacionados de alguna manera, entonces tal vez un cambio de nombre del método es el fin

Answer 4

Bueno, depende ya sea null valor es valor aceptable en su API.

Si no solo no lo acepta, no lo admite. Entonces, incluso si el consumidor va a intente para usarlo con null, el compilador romperá el problema de ambigüedad.

Answer 5

Si su API acepta un valor nulo como posible valor de parámetro, entonces debe especificarlo en la documentación y mencionar que es necesario copiarlo, y escribir algunos ejemplos de código para mostrar cómo.

Sin embargo, si no desea que el usuario use valores nulos, puede cambiar TypeA y TypeB como struct en lugar de class, si su diseño de clase lo permite.