Sollte ich Instanzvariablen in Java immer initialisiert halten oder nicht?

Question

Ich habe kürzlich ein neues Projekt gestartet und versuche, meine Instanzvariablen immer auf einen Wert zu initialisieren, so dass keiner von ihnen zu irgendeinem Zeitpunkt null ist. Kleines Beispiel unten:

public class ItemManager { 

    ItemMaster itemMaster; 
    List<ItemComponentManager> components; 

    ItemManager() { 
    itemMaster = new ItemMaster(); 
    components = new ArrayList<ItemComponentManager>(); 
    } 

    ... 
} 

Der Punkt in erster Linie ist die langwierige Prüfung für null, bevor Sie eine Instanz Variable irgendwo im Code zu vermeiden. Bis jetzt funktioniert es gut und Sie brauchen meistens nicht Null-Wert, wie Sie auch für leere Zeichenfolge oder leere Liste, etc. überprüfen können. Ich verwende diesen Ansatz für Method-Scoped-Variablen nicht, da ihr Umfang sehr begrenzt ist und wirkt sich daher nicht auf andere Teile des Codes aus.

Das alles ist irgendwie experimentell, also würde ich gerne wissen, ob dieser Ansatz funktionieren könnte oder ob es einige Fallstricke gibt, die ich noch nicht sehe. Ist es generell eine gute Idee, Instanzvariablen initialisiert zu halten?

Answer 1

Ich behandle in der Regel eine leere Sammlung und eine Null-Sammlung als zwei getrennte Dinge:

Eine leere Sammlung bedeutet, dass ich weiß, es gibt null Veröffentlichungen. Eine Null-Sammlung wird mir sagen, dass ich den Zustand der Sammlung nicht kenne, was eine andere Sache ist.

Also ich glaube wirklich nicht, dass es entweder/oder ist. Und ich würde die Variable endgültig deklarieren, wenn ich sie im Konstruktor initialisiere. Wenn Sie es als endgültig erklären, wird dem Leser klar, dass diese Sammlung nicht null sein kann.

Answer 2

Was passiert, wenn in einem Ihrer Methoden geschieht Sie setzen

itemMaster = null; 

oder Sie geben einen Hinweis auf die ItemManager zu einer anderen Klasse und setzt ItemMaster als null. (Sie können sich davor schützen, einen Klon von Ihrem ItemManager usw. zurückgeben)

Ich würde die Schecks behalten, wie dies möglich ist.

Answer 3

Ja, es ist eine gute Idee, alle Klassenvariablen im Konstruktor zu initialisieren.

Answer 4

Wenn es Ihr Code ist und Sie diese Konvention festlegen möchten, sollte es eine nette Sache sein. Ich stimme jedoch Pauls Kommentar zu, dass nichts daran hindert, dass ein fehlerhafter Code versehentlich eine Ihrer Klassenvariablen auf null setzt. In der Regel überprüfe ich immer auf Null. Ja, es ist ein PITA, aber defensive Codierung kann eine gute Sache sein.

Answer 5

Ich würde sagen, das ist völlig in Ordnung - solange Sie sich erinnern, dass Sie dort "leere" Platzhalterwerte haben und keine echten Daten.

Wenn Sie sie auf Null setzen, haben Sie den Vorteil, dass Sie sich mit ihnen auseinandersetzen müssen - andernfalls stürzt das Programm ab. Wenn Sie leere Objekte erstellen, diese jedoch vergessen, erhalten Sie undefinierte Ergebnisse.

Und nur um die defencive Codierung zu kommentieren - Wenn Sie derjenige sind, der die Objekte erstellt und sie niemals null setzt, ist es nicht notwendig, jedes Mal auf Null zu prüfen. Wenn Sie aus irgendeinem Grund Nullwert erhalten, dann wissen Sie, dass etwas katastrophal falsch gelaufen ist und das Programm trotzdem abstürzen sollte.

Answer 6

Der Punkt ist vor allem die mühsame Überprüfung auf null zu vermeiden, bevor eine Klassenvariable irgendwo im Code.

Sie müssen immer noch auf Null prüfen. Bibliotheken von Drittanbietern und sogar die Java-API geben manchmal null zurück.

Auch die Instanziierung eines Objekts, das niemals verwendet wird, ist verschwenderisch, aber das hängt vom Design Ihrer Klasse ab.

Answer 7

Ich würde sie final wenn möglich machen. Dann müssen sie im Konstruktor initialisiert werden und können nicht null werden.

Sie sollten sie auch in jedem Fall privat machen, um zu verhindern, dass andere Klassen ihnen null zuweisen. Wenn Sie überprüfen können, dass NULL in Ihrer Klasse niemals zugewiesen wird, funktioniert der Ansatz.

Answer 8

Ich bin auf einige Fälle gestoßen, in denen dies Probleme verursacht. Während der Deserialisierung werden einige Frameworks den Konstruktor nicht aufrufen, ich weiß nicht, wie oder warum sie dies tun, aber es passiert. Dies kann dazu führen, dass Ihre Werte null sind. Ich bin auch auf den Fall gestoßen, in dem der Konstruktor aufgerufen wird, aber aus irgendeinem Grund werden Mitgliedsvariablen nicht initialisiert.

In der Tat würde ich den folgenden Code anstelle von Ihnen verwenden:

public class ItemManager { 

    ItemMaster itemMaster = new ItemMaster(); 
    List<ItemComponentManager> components = new ArrayList<ItemComponentManager>(); 

    ItemManager() { 
    ... 
    } 
    ... 
} 

Answer 9

Ein Objekt sollte für die Verwendung 100% bereit sein, nachdem es aufgebaut ist. Benutzer sollten nicht auf Nullen achten müssen. Defensive Programmierung ist der Weg zu gehen - halten Sie die Kontrollen.

Im Interesse von DRY können Sie die Prüfungen in die Setter setzen und den Konstruktor einfach anrufen lassen. Auf diese Weise codieren Sie die Schecks nicht zweimal.

Answer 10

In erster Linie alle nicht letztinstanzlich Variablen müssen privaten deklariert werden, wenn Sie die Kontrolle behalten wollen!

Betrachten faul Instanziierung als auch - dies vermeidet auch „schlechter Zustand“, sondern initialisiert nur bei der Verwendung:

class Foo { 
    private List<X> stuff; 
    public void add(X x) { 
     if (stuff == null) 
      stuff = new ArrayList<X>(); 
     stuff.add(x); 
    } 
    public List<X> getStuff() { 
     if (stuff == null) 
      return Collections.emptyList(); 
     return Collections.unmodifiableList(stuff); 
    } 
} 

(Beachten Sie die Verwendung von Collections.unmodifiableList - es sei denn, Sie wirklich ein Anrufer in der Lage sein wollen (Hinzufügen/Entfernen von Ihrer Liste, sollten Sie es unveränderlich machen)

Denken Sie darüber nach, wie viele Instanzen des betreffenden Objekts erstellt werden. Wenn es viele gibt und Sie immer die Listen erstellen (und möglicherweise mit vielen leeren Listen enden), könnten Sie viel mehr Objekte erstellen, als Sie benötigen.

Abgesehen davon, es ist wirklich eine Frage des Geschmacks und wenn Sie sinnvolle Werte haben, wenn Sie konstruieren.

Wenn Sie mit einem DI/IOC arbeiten, wollen Sie den Rahmen für Sie die Arbeit tun (auch wenn man es durch Konstruktor Injektion tun könnte, ich ziehe Setter) - Scott

Answer 11

So wie ich mit jeder Variablen umgehen, die ich deklariere, ist zu entscheiden, ob sie sich über die Lebensdauer des Objekts (oder der Klasse, wenn es statisch ist) ändern wird.Wenn die Antwort "Nein" ist, mache ich es endgültig.

So dass es endgültige zwingen Sie ihm einen Wert geben, wenn das Objekt erstellt wird ... ich persönlich würde folgende tun, wenn ich weiß, dass ich würde ändern, was den Punkt, an:

 
    private final ItemMaster itemMaster; 
    private final List components; 

    // instance initialization block - happens at construction time 
    { 
     itemMaster = new ItemMaster(); 
     components = new ArrayList(); 
    } 

Die Art und Weise Ihr Code befindet sich gerade jetzt, Sie müssen die ganze Zeit auf Null überprüfen, da Sie die Variablen nicht als privat markiert haben (was bedeutet, dass jede Klasse im selben Paket die Werte auf null setzen kann).

Answer 12

Vom Namen der Klasse "ItemManager" klingt ItemManager in einigen Apps wie ein Singleton. Wenn ja, sollten Sie untersuchen und wirklich, wirklich, Dependency Injection kennen. Verwenden Sie etwas wie Spring (http://www.springsource.org/), um die Liste von ItemComponentManagers in ItemManager zu erstellen und zu injizieren.

Ohne DI, Initialisierung von Hand in ernsthaften Anwendungen ist ein Albtraum zu debuggen und verbinden verschiedene "Manager" -Klassen, um enge Tests ist die Hölle.

Verwenden Sie DI immer (auch beim Erstellen von Tests). Erstellen Sie für Datenobjekte eine Methode get(), die die Liste erstellt, falls sie nicht existiert. Wenn das Objekt jedoch komplex ist, wird es Ihr Leben mit dem Factory- oder Builder-Muster mit ziemlicher Sicherheit besser finden und das F/B-System die Mitgliedsvariablen nach Bedarf festlegen.