Get- und Set-Accessoren: Guter Stil - Schlechter Stil

Hallo Programmierer,

das Programmieren in C# gefällt mir als Neueinsteiger sehr gut. Jedoch tue ich mir schwer beim Thema guter Programmierstil. C# bietet Get und Set Accessor. Sind sehr schnell genutzt und machen vieles einfacher. Inwieweit ist dies aber im Sinne der OOP noch guter Stil? Wofür sind Set Accessoren gedacht? Für schnelle Entwürfe die zeigen was geht, oder auch im Endprogramm? Mir kommts dabei vor, dass das Prinzip der Kapselung und Geheimhaltung dadurch etwas gestört wird. Andererseits ist es sehr bequem. Bevor ich mir einen schlechten Stil angewöhne möchte ich euch um eure Meinung bitten.

Besten Dank

Idp

Natürlich sind Eigenschaften absolut in Ordnung und auch im Einklang mit der OOP.
Ich würde es viel eher als Defizit zB bei Java sehen, dass es sowas nicht gibt, sondern nur Felder.

Faustregel:

• Soll der Klassenwert NUR innerhalb der Klasse verfügbar sein, dann Implementierung als Feld.
• Soll Setzen oder Lesen auch Außerhalb der Klasse verfügbar sein, dann ist es eine Eigenschaft.
  Ein Feld ist ein simpler Datencontainer waehrend eine Eigenschaft auch Logik beinhalten kann.

Siehe auch Codekonventionen für C# (C#-Programmierhandbuch)

Ansonsten ist guter Stil insgesamt Geschmackssache, wozu es keine pauschale Antwort gibt.
Im Forum selbst findest Du zu Stilen schon genug Threads; das muss nicht alles nochmal genannt werden 😉

Getter und Setter verletzen das OOP-Prinzip genauso wie get und set Methoden. Also erstmal garnicht, bei extensivem gebrauch bekommt das ganze aber einen Geschmack.

Du kannst in einem Getter etwas berechnen, also nur weil es ein Getter gibt muss dahinter noch lange kein Feld stehen. Insofern Kapselt ein Getter. Auch ein Setter muss nicht unmittelbar in ein Feld schreiben, könnte also z.B. einen Setter von einem privaten Objekt aufrufen.

Insofern kapseln sowohl Getter und Setter die Implementierung, sind daher guter OOP-Stil.

Ein Problem wird das ganze dann, wenn man - weil es ja so schön einfach ist - aus jedem privaten Feld ein Property macht ung {get; set;} dahinter schreibt. Dann verletzt man die OOP-Prinzipien.

Generell gilt für alles, was public ist: So viel wie nötig, so wenig wie möglich. Das gilt auch für Properties.

Hallo idempotenz,

Inwieweit ist dies aber im Sinne der OOP noch guter Stil?

Accessoren - besser gesagt die Properties, den die Accessoren gehören - stehen voll im Einklang mit OOP. Viel, viel mehr und besser als Get- und Set-Methoden.

Mal abgesehen dass es auch private Properties geben kann, die offensichtlich die Kapselung schon prinzipiell nicht gefährden können, konzentriere ich mich im folgenden auf öffentliche Properties, um die es ja auch dir offensichtlich geht.

Wofür sind Set Accessoren gedacht?

Wie der Name sagt, für den Zugriff auf den Zustand des Objekts - natürlich nur soweit dieser nach außen bekannt und/oder änderbar sein soll.

Für schnelle Entwürfe die zeigen was geht, oder auch im Endprogramm?

Selbstverständlich sind Accessoren/Properties integraler Bestandteil eines jedes Programms, also natürlich auch des fertigen, produktiven Programms.

Mir kommts dabei vor, dass das Prinzip der Kapselung und Geheimhaltung dadurch etwas gestört wird.

Nein! Erstens kann man als Programmierer der Klasse selbst selbst bestimmen, worauf Zugriff gewährt wird und worauf nicht. Also insbesondere welche Teile des Zustands nur gelesen oder nur geändert werden dürfen oder beides zusammen.

Zum anderen kann man bei Settern den Input prüfen und bei Bedarf auch ablehnen sowie weitere Aktionen, die nach einer Änderung ggf. nötig sind, durchführen. Somit hat man die volle Kontrolle. Die Kapselung des Objekts bleibt voll erhalten. Man kann sicherstellen, dass sich das Objekt immer in einem gültigen Zustand befindet.

Andererseits ist es sehr bequem.

Das ist ein netter Nebeneffekt, aber keinesfalls der Hauptgrund für die Einführung. Der Hauptgrund ist, dass Accessoren/Properties konzeptionell klarer sind und sich besser in OOP einfügen als Get- und Set-Methoden.

Bevor ich mir einen schlechten Stil angewöhne möchte ich euch um eure Meinung bitten.

Verwende immer Accessoren/Properties, nie Get- und Set-Methoden und nie öffentliche Felder.

Ein (echtes) Objekt besteht immer aus Zustand und Verhalten (und Identität, was hier jedoch keine Rolle spielt). Zustand und Verhalten sind konzeptionell unterschiedlich, weshalb es sinnvoll und richtig ist, für beides unterschiedliche angepasste Konstrukte zu verwenden. (Öffentlich) Properties repräsentieren den (äußeren) Zustand des Objekts (wie er sich für den Verwender darstellt) und ermöglichen dessen Änderung. Methoden repräsentieren das Verhalten des Objekts. Näheres dazu, welche Rolle der Zustand eines Objekts spielt, findest du in Untersch. Behandlung der Objektdaten bzgl. Modifizierer bei Serialisierung in den versch. Formaten.

Bitte beachte [Hinweis] Wie poste ich richtig? Punkt 1.1.1.

herbivore

PS: Die Frage, wie offen oder wie gekapselt ein Objekt sein sollte, damit es praktikabel und (gleichzeitig?) sicher einsetzbar ist, wurde in 3-Schichten-Design?? [harte vs. weiche (Daten-)Objekte / OOP vs. ActiveRecords] ausführlich diskutiert.