java - sale - null pointer exception traducir

¿Los argumentos NULL son una mala práctica?

Question

¿Es una mala práctica pasar el argumento NULL a los métodos o, en otras palabras, deberíamos tener definiciones de métodos que permitan el argumento NULL como un argumento válido?

Supongamos que quiero dos métodos 1. para recuperar la lista de todas las compañías 2. para recuperar la lista de compañías según el filtro.

Podemos tener dos métodos como el siguiente

    List<Company> getAllCompaniesList();
    List<Company> getCompaniesList(Company companyFilter);

o podemos tener un solo método

    List<Company> getCompaniesList(Company companyFilter);

aquí en el segundo caso, si el argumento es NULL, el método devuelve la lista de todas las compañías.

Además de las buenas prácticas, veo un problema más con un enfoque posterior que se explica a continuación.

Estoy implementando Spring AOP, en el que quiero revisar algunos argumentos como 1. ¿Es el argumento NULO? 2. ¿Es el tamaño de la colección 0?

Hay algunos escenarios en los que no podemos tener ningún argumento nulo como para el método

    void addBranches(int companyId, List<Branch>);

Esta verificación se puede realizar muy bien usando Spring AOP definiendo un método como el siguiente

@Before(argNames="args", value="execution(* *)")
void beforeCall(JoinPoint joinPoint ,Object[] args )
{ 
           foreach(Object obj in args)
           {
                 if(obj == NULL)
                 {
                     throw new Exception("Argument NULL");
                 } 
           }   
}

Pero el problema al que me enfrento es que he definido algunos de los métodos que deberían aceptar el argumento NULL para una funcionalidad múltiple de un solo método como se mencionó anteriormente para el método List getCompaniesList (Company companyFilter); Por lo tanto, no puedo aplicar AOP uniformemente para todos los métodos y ninguna expresión para la coincidencia de nombres de métodos será útil aquí.

Por favor, avíseme si se requiere más información o si el problema no es lo suficientemente descriptivo.

Gracias por leer mi problema y pensar en ello.

Answer 1

Es una práctica común, pero hay maneras de hacer que su código sea más claro: evitar los cheques nulos a veces o moverlos a otra parte. Busque el patrón de objetos nulos; puede que sea exactamente lo que necesita: http://en.m.wikipedia.org/wiki/Null_Object_pattern?wasRedirected=true

Answer 2

Está bien, en los casos en que hay demasiados métodos sobrecargados. Así que en lugar de tener todas las combinaciones de parámetros, permite que algunos de ellos sean null . Pero si lo haces, documenta esto explícitamente con

@param foo foo description. Can be null

En su caso, tendría los dos métodos, donde el primero invoca al segundo con un argumento null . Hace que la API sea más usable.

No hay una línea estricta donde detener la sobrecarga y dónde comenzar a confiar en los parámetros que admiten nulos. Es una cuestión de preferencia. Pero tenga en cuenta que así su método con la mayoría de los parámetros permitirá que algunos de ellos sean anulables, así que documente esto también.

También tenga en cuenta que una forma preferida de hacer frente a múltiples parámetros del constructor es a través de un Generador. Así que en lugar de:

public Foo(String bar, String baz, int fooo, double barr, String asd);

donde cada uno de los argumentos es opcional, puedes tener:

Foo foo = new FooBuilder().setBar(bar).setFooo(fooo).build();

Answer 3

La regla es: interfaz simple, implementación complicada.

Las decisiones de diseño acerca de su API se deben tomar considerando cómo es probable que el código del cliente lo use. Si esperas ver alguna de las dos

getAllCompaniesList(null);

o

if (companyFilter == null) {
    getAllCompaniesList();
} else {
    getAllCompaniesList(companyFilter);
}

entonces lo estás haciendo mal. Si el caso de uso probable es que el código del cliente, en el momento en que se escribe, tenga o no un filtro, debe proporcionar dos puntos de entrada; Si esa decisión probablemente no se toma hasta el tiempo de ejecución, permita un argumento nulo.

Answer 4

Otro enfoque que puede ser viable puede ser tener una interfaz CompanyFilter con un método companyIsIncluded(Company) que acepte una Company y devuelva verdadero o falso para decir si se debe incluir alguna compañía. Company podría implementar la interfaz para que el comportamiento del método companyIsIncluded reflejado sea equals() , pero uno podría fácilmente tener un CompanyFilter.AllCompanies companyIsIncluded() cuyo método companyIsIncluded() siempre devolvería verdadero. Usando ese enfoque, no hay necesidad de pasar un valor nulo, simplemente pase una referencia al singleton AllComapnies .

Answer 5

Yo uso una regla muy simple:

Nunca permita el valor nulo como argumento o valor de retorno en un método público.

Hago uso de Optional y Preconditions o AOP para hacer cumplir esa regla. Esta decisión ya me ahorró muchas horas de corrección de errores después de NPE o un comportamiento extraño.