Sind NULL-Argumente eine schlechte Übung?

Question

Ist es eine schlechte Übung, ein NULL-Argument an Methoden zu übergeben, oder mit anderen Worten, sollten wir Methodendefinitionen haben, die das NULL-Argument als gültiges Argument zulassen.

Angenommen, ich möchte zwei Methode 1. Liste aller Unternehmen abrufen 2. Liste der Unternehmen basierend auf Filter abrufen.

Wir können entweder zwei Methoden wie wie unten

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

oder wir können eine einzige Methode haben

List<Company> getCompaniesList(Company companyFilter); 

hier in zweiten Fall, wenn Argument NULL ist dann Methode Rückkehr Liste aller Firmen.

Neben der Frage der guten Praxis sehe ich ein weiteres Problem mit dem späteren Ansatz, der unten erklärt wird.

Ich implementiere Spring AOP, in dem ich einige Überprüfungen auf Argumente wie haben möchte 1. Ist Argument NULL? 2. ist Größe der Sammlung 0?

Es gibt einige Szenarien, in denen wir Null-Argument nicht wie für Verfahren

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

Diese Prüfung sehr gut mit Spring AOP durch die Definition von Verfahren wie folgt

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

durchgeführt werden können, haben kann Aber das Problem, dem ich gegenüberstehe, ist, da ich einige Methoden definiert habe, die NULL-Argument für mehrere Funktionen einer einzelnen Methode akzeptieren sollten, wie oben für Methode List getCompaniesList (Firma companyFilter) erwähnt; So kann ich AOP nicht einheitlich für alle Methoden anwenden, und weder irgendein Ausdruck für die Methodennamensübereinstimmung wird hier nützlich sein.

Bitte lassen Sie mich wissen, wenn mehr Informationen benötigt werden oder das Problem nicht beschreibend genug ist.

Danke, dass Sie mein Problem gelesen haben und darüber nachgedacht haben.

Answer 1

Es ist in Ordnung, wenn es zu viele überladene Methoden gibt. Anstatt alle Kombinationen von Parametern zuzulassen, lassen Sie einige davon null zu. Aber wenn Sie dies tun, dokumentieren dies ausdrücklich mit

@param foo foo description. Can be null 

In Ihrem Fall würde ich die beiden Methoden haben, wobei der erste die zweite mit einem null Argument aufruft. Es macht die API brauchbarer.

Es gibt keine strikte Linie, wo die Überladung gestoppt werden kann und wo man sich auf NULL-fähige Parameter verlassen kann. Es ist eine Frage der Präferenz. Beachten Sie jedoch, dass Ihre Methode mit den meisten Parametern es erlaubt, dass einige von ihnen nullfähig sind, also dokumentieren Sie dies ebenfalls.

---

Beachten Sie auch, dass eine bevorzugte Möglichkeit, mehrere Konstruktorparameter zu bewältigen, über einen Builder ist. Also statt:

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

, wo jedes der Argumente optional ist, können Sie haben:

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

Answer 2

Es ist gängige Praxis, aber es gibt Möglichkeiten, um Ihren Code klarer zu machen - vermeiden Sie Null-Check-in manchmal, oder verschieben Sie sie woanders hin. Schauen Sie sich das Null-Objektmuster an - es kann genau das sein, was Sie brauchen: http://en.m.wikipedia.org/wiki/Null_Object_pattern?wasRedirected=true

Answer 3

Die Regel lautet: einfache Schnittstelle, komplizierte Implementierung.

Designentscheidungen über Ihre API sollten getroffen werden, indem Sie überlegen, wie der Clientcode sie wahrscheinlich verwendet. Wenn Sie erwarten, entweder

getAllCompaniesList(null); 

oder

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

dann zu sehen, Sie tun es falsch. Wenn der Client-Code wahrscheinlich zum Zeitpunkt des Schreibens entweder einen Filter hat oder nicht, sollten Sie zwei Einstiegspunkte angeben. Wenn diese Entscheidung wahrscheinlich erst zur Laufzeit erfolgt, lassen Sie ein Null-Argument zu.

Answer 4

verwende ich eine sehr einfache Regel:

nie als Argument null zulassen oder Wert auf eine öffentliche Methode zurückzukehren.

Ich verwende Optional und Preconditions oder AOP, um diese Regel zu erzwingen. Diese Entscheidung hat mir bereits viele Stunden vor dem Beheben von Fehlern durch NPE oder seltsames Verhalten gerettet.

Answer 5

Ein weiterer Ansatz, praktikabel sein kann, kann eine CompanyFilter Schnittstelle mit einer companyIsIncluded(Company) Methode zu haben, die ein Company akzeptiert und gibt wahr oder falsch zu sagen, ob ein Unternehmen aufgenommen werden sollte. Company könnte die Schnittstelle implementieren, so dass Verhalten der Methode gespiegelt equals(), aber man könnte leicht ein Singleton CompanyFilter.AllCompanies, deren companyIsIncluded() Methode immer True zurückgegeben würde. Bei Verwendung dieses Ansatzes ist es nicht notwendig, einen Nullwert zu übergeben - übergeben Sie einfach einen Verweis auf den Singleton AllComapnies.