Hahne Geschrieben 8. Februar 2010 Geschrieben 8. Februar 2010 Hallo, ich habe in einer Klasse ein Getter/Setter für eine List<string> implementiert. Erstelle ich von dieser KLasse ein Objekt und möchte in meiner List etwas abspeichern erhalte ich die Fehlermeldung Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.. Warum ist mir auch klar. Nun habe ich dieses folgendermaßen gelöst: public class Class1 { public Class1() { this.StringCollection = new List<string>(); } public List<string> StringCollection { get; set; } } Ist das schon optimal gelöst oder gibt es eine bessere Möglichkeit? Zitieren
El Ninjo Geschrieben 8. Februar 2010 Geschrieben 8. Februar 2010 Ist das schon optimal gelöst oder gibt es eine bessere Möglichkeit? Wozu benötigst du denn die Klasse beziehungsweise, was spricht gegen die vorhandene .NET-Klasse? Zitieren
autschen Geschrieben 8. Februar 2010 Geschrieben 8. Februar 2010 List<string> test = new List<string>(); public List<string> Test { get { return test; } set { test = value; } } versuch mal sowas! Zitieren
Hahne Geschrieben 8. Februar 2010 Autor Geschrieben 8. Februar 2010 List<string> test = new List<string>(); public List<string> Test { get { return test; } set { test = value; } } versuch mal sowas! Hmm, joa würde theoretisch auch gehen aber ich glaube dann wäre dieses hier doch schöner oder? List<string> test = new List<string>(); public List<string> Test { get { if(test == null) test = new List<string>(); return test; } set { test = value; } } Zitieren
JasonDelife Geschrieben 8. Februar 2010 Geschrieben 8. Februar 2010 Wenn man nicht will, dass ein Property null ist, dann prüft man üblicherweise im Setter auf null und wirft entsprechend eine Exception. Grüße, JasonDelife. Zitieren
Hahne Geschrieben 8. Februar 2010 Autor Geschrieben 8. Februar 2010 Oh stimmt sorry wollte es auch in den Setter setzen... Habs verdreht. Zitieren
lbm1305 Geschrieben 8. Februar 2010 Geschrieben 8. Februar 2010 Wenn man nicht will, dass ein Property null ist, dann prüft man üblicherweise im Setter auf null und wirft entsprechend eine Exception. Grüße, JasonDelife. Den Setter setzt man eher auf private. Die Überprüfung auf null erfolgt im Getter. Zitieren
Hahne Geschrieben 8. Februar 2010 Autor Geschrieben 8. Februar 2010 Hä was denn jetzt? Zwei Aussagen und beide unterschiedlich. Für mich ist die Prüfung auf null im Setter logischer. Meine Meinung. Zitieren
lbm1305 Geschrieben 8. Februar 2010 Geschrieben 8. Februar 2010 Hä was denn jetzt? Zwei Aussagen und beide unterschiedlich. Für mich ist die Prüfung auf null im Setter logischer. Meine Meinung. Ich antworte mal mit einer Gegenfrage. Wozu soll der öffentliche Setter gut sein? Zitieren
autschen Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 (bearbeitet) eigentlich prüft man in der set und get methode überhaupt nichtst sonder da wo man sie aufruft Bearbeitet 9. Februar 2010 von autschen Zitieren
lbm1305 Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Ich antworte mal mit einer Gegenfrage. Wozu soll der öffentliche Setter gut sein? Ich muss die Frage korrigieren. Wozu brauche ich einen (öffentlichentlichen) Setter, wenn ich nur eine Liste zurückgeben möchte? Zitieren
Hahne Geschrieben 9. Februar 2010 Autor Geschrieben 9. Februar 2010 Ich muss die Frage korrigieren. Wozu brauche ich einen (öffentlichentlichen) Setter, wenn ich nur eine Liste zurückgeben möchte? Damit ich neue Werte in meine Liste hinzufügen kann mit der Hilfe von "Add" Zitieren
autschen Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 das ist nicht ganz der sinn der sache das würde auch so gehen guck dir mal den link an Datenkapselung (Programmierung) ? Wikipedia Zitieren
lbm1305 Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Damit ich neue Werte in meine Liste hinzufügen kann mit der Hilfe von "Add" Das Property ist nicht für den Inhalt der Liste zuständig, sondern das Property repräsentiert die Liste selber. Auch wenn das List-Property nur einen Getter hat, sind die die Methoden der Liste voll verfügbar. In diesem Fall (Setter fehlt oder ist private) kann ich dem Objekt keine neue Liste hinzufügen bzw. die bestehende ändern. Meistens werden Collections aber aus dem Objekt heraus erstellt. Der Getter gibt diese halt nur nach außen ab. Zitieren
El Ninjo Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Auch wenn das List-Property nur einen Getter hat, sind die die Methoden der Liste voll verfügbar. In diesem Fall (Setter fehlt oder ist private) kann ich dem Objekt keine neue Liste hinzufügen bzw. die bestehende ändern. Meistens werden Collections aber aus dem Objekt heraus erstellt. Der Getter gibt diese halt nur nach außen ab. Somit ist ohne Setter das Verändern der Liste nur über die eigenen Methode der Liste möglich, wird also von ihr selbst gesteuert. Der direkte Zugriff von außerhalb ist ausgeschlossen, so wie es die Datenkapselung vorsieht. Zitieren
Hahne Geschrieben 9. Februar 2010 Autor Geschrieben 9. Februar 2010 Ich komme dda gerade nicht ganz hinterher... wie genau würde das jetzt aussehen? Ok, dass mein List Objekt das hinzufügen von neuen Werten selbst steuert ist mir jetzt klar aber ich muss ja noch das Problem mit der NullReferenceException beheben. Wie soll ich das denn machen wenn ich nur einen Getter hab? Zitieren
El Ninjo Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 aber ich muss ja noch das Problem mit der NullReferenceException beheben. Wie soll ich das denn machen wenn ich nur einen Getter hab? Das Problem wird nur dann auftreten, wenn du die Liste innerhalb der Klasse explizit auf null setzt oder nicht initialisiert. Sinnvoll wäre auch zur Sicherheit an jeder Stelle, wo du über den Getter auf die Liste zugreifst abfragst, ob sie null ist und deine Anweisungen nur dann ausführst, wenn dies nicht der Fall ist. Zitieren
lbm1305 Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Ich komme dda gerade nicht ganz hinterher... wie genau würde das jetzt aussehen? Ok, dass mein List Objekt das hinzufügen von neuen Werten selbst steuert ist mir jetzt klar aber ich muss ja noch das Problem mit der NullReferenceException beheben. Wie soll ich das denn machen wenn ich nur einen Getter hab? public class Foo { // Private Fields private IEnumerable<int> _internalList; // Methods private IEnumerable<int> LoadCollection() { _internalList = Enumerable.Range(1, 100); return _internalList; } // Properties public IEnumerable<int> Zahlen { get { if ( _internalList == null ) _internalList = LoadCollection(); return _internalList; } } } Zitieren
El Ninjo Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 das geht auch einfacher: private IEnumerable<int> _internalList = Enumerable.Range(1, 100); public IEnumerable<int> Zahlen { get { return _internalList; } } Zitieren
lbm1305 Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 das geht auch einfacher: private IEnumerable<int> _internalList = Enumerable.Range(1, 100); public IEnumerable<int> Zahlen { get { return _internalList; } } Sicher... ;-) Zitieren
LadyPreis Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 eigentlich prüft man in der set und get methode überhaupt nichtst sonder da wo man sie aufruft Du hast da aber anscheinend den Sinn von Gettern/Settern nicht verstanden. Denn Genau für diese Überprüfungen sind sie da, damit man nicht an 50 anderen Stellen im Projekt die gleiche Überprüfung machen muss. Das Stichwort heisst "Wartbarkeit" Zitieren
realgun Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 private IEnumerable<int> LoadCollection() { _internalList = Enumerable.Range(1, 100); return _internalList; } Welchen Sinn hat denn hier bitte das Return bzw. der Rückgabewert der Methode? Zitieren
lbm1305 Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Welchen Sinn hat denn hier bitte das Return bzw. der Rückgabewert der Methode? Rückgabe eines Objekts, welches das generische Interface IEnumerable<T> implementiert!? warum eine Methode? Weil dann die Möglichkeit bestände, die Methode LoadCollection() explizit von einem möglich Interface IFoo zu implementieren. Zitieren
realgun Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Rückgabe eines Objekts, welches das generische Interface IEnumerable<T> implementiert!? warum eine Methode? Weil dann die Möglichkeit bestände, die Methode LoadCollection() explizit von einem möglich Interface IFoo zu implementieren. Sorry, Du hast mich falsch verstanden. Der Rückgabewert dieser Methode ist vollkommen sinnlos, da die Methode das private Feld "_internalList" ja bereits setzt. Und da die Methode ja selber auch private ist, hat sie keinen Mehrwert. Im Gegenteil, es wird eine unnötige Zuweisung vorgenommen, genauso wie bei der Verwendung in: <code> if ( _internalList == null ) _internalList = LoadCollection(); </code> Da das Feld "_internalList" ja bereits in der Methode "LoadCollection()" gesetzt wird, ist eine nochmalige Zuweisung total überflüssig. Schöne Grüße, realgun Zitieren
lbm1305 Geschrieben 9. Februar 2010 Geschrieben 9. Februar 2010 Sorry, Du hast mich falsch verstanden. Der Rückgabewert dieser Methode ist vollkommen sinnlos, da die Methode das private Feld "_internalList" ja bereits setzt. Und da die Methode ja selber auch private ist, hat sie keinen Mehrwert. Im Gegenteil, es wird eine unnötige Zuweisung vorgenommen, genauso wie bei der Verwendung in: <code> if ( _internalList == null ) _internalList = LoadCollection(); </code> Da das Feld "_internalList" ja bereits in der Methode "LoadCollection()" gesetzt wird, ist eine nochmalige Zuweisung total überflüssig. Schöne Grüße, realgun Stimmt. Hatte ich übersehen. Es war eher so gedacht, dass die Klasse Foo noch ein Interface IFoo bzw. die Methode explizit implementiert. sicherlich würde es reichen private IEnumerable<int> LoadCollection() { return Enumerable.Range(1,100); } Zitieren
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.