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?

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?

        List<string> test = new List<string>();


        public List<string> Test

        {

            get { return test; }

            set { test = value; }

        }

versuch mal sowas!

        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; }

}

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.

Oh stimmt sorry wollte es auch in den Setter setzen... Habs verdreht.

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.

Hä was denn jetzt? Zwei Aussagen und beide unterschiedlich. Für mich ist die Prüfung auf null im Setter logischer. Meine Meinung.

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?

eigentlich prüft man in der set und get methode überhaupt nichtst sonder da wo man sie aufruft

Bearbeitet 9. Februar 201015 j von autschen

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?

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"

das ist nicht ganz der sinn der sache das würde auch so gehen guck dir mal den link an

Datenkapselung (Programmierung) ? Wikipedia

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.

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.

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?

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.

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;

      }

    }

  }

das geht auch einfacher:

private IEnumerable<int> _internalList = Enumerable.Range(1, 100);


public IEnumerable<int> Zahlen

{

 get

  {       

    return _internalList;

  }

}

das geht auch einfacher:

private IEnumerable<int> _internalList = Enumerable.Range(1, 100);


public IEnumerable<int> Zahlen

{

 get

  {       

    return _internalList;

  }

}

Sicher... ;-)

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"

    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?

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.

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

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);

}