Entwickler-Ecke :: Thema anzeigen

storestore - So 25.09.11 18:31
Titel: get und set

Hi,
ich habe mal eine frage:wofür gibt es get und set in c#?
Kennt ihr eine einfache erklärung? Alle erklärungen von msdn sind immer so komplex!
mfg storestore

Moderiert von Th69: Titel geändert.

ujr - So 25.09.11 21:49

storestore hat folgendes geschrieben :

Alle erklärungen von msdn sind immer so komplex!

Welche Seite meinst Du genau und was verstehst Du da nicht?

Das Stichwort ist im übrigen "Properties".

storestore - So 25.09.11 22:15

Im allgemeinen wenn man es googled

ujr - So 25.09.11 23:32

storestore hat folgendes geschrieben :

Im allgemeinen wenn man es googled

Ja, eben: "C# Properties" findet doch jede Menge gute Erklärungen. Um diese nicht alle zu wiederholen, müsstest Du mitteilen, was Du nicht verstehst.

storestore - Mo 26.09.11 18:55

Also,
get und set brauche ich wenn ich jetzt einen wert einer Variable habe und ihn ausgeben möchte. Damit ich immer den wert dieser Variable drin habe ohne das er sich ändert benutze ich get und set.
Kann man das nicht auch so lösen
int varibale=0;
int variable2= variable;
dann hat man doch das gleiche erziehlt, oder?

Horschdware - Mo 26.09.11 21:05

Man informiere sich über das Konzept der Datenkapselung.

Dr. Hallo - Di 27.09.11 13:46

storestore hat folgendes geschrieben :

Also,
Kann man das nicht auch so lösen
int varibale=0;
int variable2= variable;

na klar, kann mans auch so machen. wenn die variable aber zb nur werte in einem bestimmten bereich aufnehmen soll/darf, musst du eine zugriffsfunktion schreiben in der vorher der übergebene wert auf gültigkeit geprüft wird.

pdelvo - Di 27.09.11 15:43

Bei dem Wiki Artikel gefällt mir der erste Satz nicht. Eine Eigencschafft muss keine Sicht auf eine variable sein. Es kann eine sein.

C#-Quelltext

1:	public bool ReadOnly{ get{ return false; } }

Ist genauso valide. Und in dem Fall ist es eine konstante und keine Variable. Oder jegliches anderes Konstrukt

thepaine91 - Di 27.09.11 16:26

Wobei ich keinen Sinn sehe eine Konstante nicht auch als solche zu deklarieren? Hast du dafür ein sinnvolles Beispiel?

Ralf Jansen - Di 27.09.11 16:39

Zitat:

Wobei ich keinen Sinn sehe eine Konstante nicht auch als solche zu deklarieren?

Bei einer öffentlichen Konstante kann es so zumindest sinnvoller sein als das const Schlüsselwort. Wenn du die Konstante doch mal änderst müsstest du sonst alle anderen Assemblies die die Konstante benutzen neu kompilieren. Sonst würden die nicht kompilierten Assemblies weiterhin den alten Konstantenwert verwenden(Konstanten werden rein kompiliert nicht referenziert!). Ein echtes readOnly(ich meine hier das Schlüsselwort) Feld ginge aber genauso.

pdelvo - Di 27.09.11 19:53

Ein Beispiel wäre zB die implementation eines INterfaces. zum beispiel jedes array implementiert IList. Und das verlangt unter anderem das property Readonly. und bei arrays ist das ein return false ;)

C# - Di 27.09.11 22:05

Also ich habe jetzt nur die ersten Beiträge gelesen deshalb sry wenn ich etwas aus dem Zusammenhang reiße. Aber wenn man die Erklärungen von msdn nicht versteht - insbesondere bei get, set sollte man nicht zuerst mal ein Grundlagenbuch oder ähnliches durchlesen?

storestore - Mi 28.09.11 15:32

C# hat folgendes geschrieben :

sollte man nicht zuerst mal ein Grundlagenbuch oder ähnliches durchlesen?

Bin i gerade dabei :roll:
Außerdem, sollte man das immer machen!
Edit: Mein Problem hat sich erldeigt. Danke Leute! ;)

Horschdware - Mi 28.09.11 16:00

Also irgendwie beisst sich deine Aussage, dass du gerade ein Grundlagenbuch durcharbeitest mit deinem neuen Thread, in dem du nach Büchern für Fortgeschrittene suchst, weil du mit deinem Einsteigerbuch fertig bist.

storestore - Mi 28.09.11 16:01

Naja, bin noch nicht ganz fertig! ;) *Erwischt* :mrgreen:
Habs gelöst. Das Video hat mir geholfen
http://www.youtube.com/watch?v=kHcGMui_cRY

pdelvo - Do 06.10.11 17:19

Hab mir das Video mal angesehen. Meiner Meinung nach wird da ziemlich viel Halbwissen und falsches Zeugs erzählt. 1. gibt es keine Funktionen, nur Methoden. Das was man laut ihm "Funktion oder so" nennt sind 2 Methoden. Properties ist eine vereinfachte Schreibweise für 2 Methoden(mit kleinen Optimierungen, Stichwort inlining). Wenn man Inlining außer Betracht lässt ergibt sich für die Properties noch ein paar andere Eigenschaften gegenüber Variablen. Intern wird der Stacktrace verändert(es wird in die Methode gesprungen) das hat man bei Variablen nicht. Bei einem Property ist der setter optional, dh. man braucht ihn nicht hinzuzufügen. Ein setter kann eine andere Sichtbarkeit haben als der getter. Eine Variable kann man nach außen hin nicht schreibgeschützt machen, und von innen beschreibbar.

Dann gibt es noch eine abgekürzte Schreibeise für Properties

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:

public int Count{ get; set; }

//daraus macht der Compiler

int backend_count;

public int Count
{
     get
     {
          return backend_count;
     }
     set
     {
          backend_count = value;
     }
}

Dann gibt es noch Unterschiede, wenn ein Property einen Wertetyp zurückgibt:

C#-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:

    class Test0
    {
        static void Main(string[] args)
        {
            Test1 testKlasse = new Test1();
            testKlasse.Variable.V = 1;//Funktioniert
            testKlasse.Property.V = 1;//Fehler
        }
    }

    class Test1
    {
        public Test2 Variable;

        public Test2 Property
        {
            get
            {
                return Variable;
            }
            set
            {
                Variable = value;
            }
        }

        public Test1()
        {
            Test2 t = new Test2();
            t.V = 5;
            Property = t;
        }
    }
    struct Test2
    {
        public int V;
    }

Beim Aufruf des getters wird eine Kopie erzeugt, da Test2 ein Wertetyp ist. Deswegen würde das setzen von V eine Kopie ändern, und nicht das V aus Test2. Deswegen gibt es dort einen Fehler. Bei Referenztypen wird dabei eine Kopie des Zeigers auf das Objekt erzeugt, und so kann dann das Objekt selbst geändert werden.

Wahrscheinlich gibts noch ne Reihe mehr andere Verhaltensweisen. Nur in dem Video klang es so, dass Properties = Variablen + Codeblock sind. Und das wollte ich nicht so stehen lassen