Weil man Properties z.B. über BindingSources an CEs wie ne ComboBox binden kann (klappt mit "normalen" Variablen nicht). Und weil man mehr als nur z.B. den Zuweisungscode bei Set ausführen lassen kann, z.B. kann man das PropertyChangedEvent feuern, welches das GUI über Änderungen informiert. Oder man kann Wertprüfungen durchführen, um Änderungen abzulehnen. Oder, oder, oder ...

##########

Man kann auch z.B. den Getter Public und den Setter Private machen. Dann kann man von außen nur lesend auf die Property zugreifen aber innerhalb der Klasse auch schreibend.
Was meinst Du mit

Visual_Prog schrieb:

Der Zugriff ist bei der VAriable einfacher weil ich nur einen schritt brauche, nicht zwei wie bei der Property

Denn man kann ja eben schreiben:
So wie bei der normalen Variable auch. Wo braucht man da n 2. Schritt?

Dass man die Property auch vereinfachen kann zu dem hier, weißt Du?

Visual_Prog schrieb:

Wieso wird trotzdem so auf Property plädiert?

Pauschal-Plädierern würde ich auch gleich widersprechen.
Wenn man eine Property braucht, soll man eine Property nehmen, sonst nicht.
Wurde schon gesagt: Databinding ist zB ein guter Grund, eine Property zu nehmen.
Auch kann man in Getter/Setter immer bischen Logik unterbringen - wie gesagt: Wenn man das braucht, soll man das machen.

Es gibt auch Gründe, eine Property nicht zu nehmen: Vielleicht will man ja bewusst Databinding ausschliessen.
Oder bei der Entwicklung von Controls ists manchmal echt lästig, was der Form-Designer sich einfallen lässt, an Code zu generieren, wenn er eine Property entdeckt.

Oder aber es ist einfach egal.
Der Geschwindigkeits-Vorteil einer Variable ist jedenfalls wirklich nicht der Rede wert.

Ah - was bei Property auch interessant sein kann ist die Möglichkeit, sie Public Readonly zu designen, innerhalb der Klasse aber beschreibbar.

@Visual_Prog Es gibt da das Control PropertyGrid, mit dem kannst Du die Properties, nicht aber Variablen, einer Klasseninstanz editieren:
docs.microsoft.com/de-de/dotne…rid?view=netframework-4.8