Hahne Geschrieben 8. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
El Ninjo Geschrieben 8. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
autschen Geschrieben 8. Februar 2010 Teilen Geschrieben 8. Februar 2010 List<string> test = new List<string>(); public List<string> Test { get { return test; } set { test = value; } } versuch mal sowas! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Hahne Geschrieben 8. Februar 2010 Autor Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
JasonDelife Geschrieben 8. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Hahne Geschrieben 8. Februar 2010 Autor Teilen Geschrieben 8. Februar 2010 Oh stimmt sorry wollte es auch in den Setter setzen... Habs verdreht. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 8. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Hahne Geschrieben 8. Februar 2010 Autor Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 8. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
autschen Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Hahne Geschrieben 9. Februar 2010 Autor Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
autschen Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
El Ninjo Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Hahne Geschrieben 9. Februar 2010 Autor Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
El Ninjo Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
El Ninjo Geschrieben 9. Februar 2010 Teilen Geschrieben 9. Februar 2010 das geht auch einfacher: private IEnumerable<int> _internalList = Enumerable.Range(1, 100); public IEnumerable<int> Zahlen { get { return _internalList; } } Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
LadyPreis Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
realgun Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
realgun Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
lbm1305 Geschrieben 9. Februar 2010 Teilen 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 Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
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.