03.4b Property, Auto-Property, init in C#

Gesamtliste aller Videos, samt Suchfunktion:
www.j3L7h.de/vi...

[@MaPhy]

Moin, Herr Professor! Das ist ja alles sehr "luxuriös" geworden, das Programmieren. Wenn ich an Assembler denke,...

[@JoernLoviscach]

Irgendwofür muss man die Gigabytes und die Gigahertz ja verbraten, sonst könnten alle ihren 30 Jahre alten Rechner behalten! Und wo kämen wir da hin!

[@MaPhy]

@@JoernLoviscach Stimmt. Schöne Feiertage!

[@_nikeee]

Für den Getter gibt es auch noch eine weitere Möglichkeit, ihn zu schreiben: public double Höhe => x; Ist dann praktisch, wenn man einen berechneten Ausdruck angeben will und nicht public double Höhe { get { return x; } } Schreiben möchte. Ist aber keine Auto-Property, da hier keine Felder vom Compiler generiert werden. Nur etwas schönere Schreibweise für nicht-Konstante Getter-Only.

[@JoernLoviscach]

Ja, die Schreibweise nach Art eines Lambda-Ausdrucks gilt aber für alle Methoden. Deshalb habe ich die hier nicht auch noch reingepackt.

[@_nikeee]

@@JoernLoviscach Die Expression-Bodied-Members ansich kamen bei Methoden und Properties zu jeweils unterschiedlichen Zeitpunkten. Macht aber auch didaktisch nicht viel Sinn, das noch mit aufzunehmen. Verwirrt mehr, als es nützt. Die Featureitis hat da aber auch noch nicht Halt gemacht. Es gibt auch noch das: public double Höhe { get => x; } ...was es nicht einfacher macht.

[@kernbeier1612]

Bei einem einfachen "public double Länge {get; set;}" kann auch jeder jeden mist reinschreiben. Gibt es auch in diese Fall einen Sinn wieso man Properties verwenden sollte und nicht einfach "public double länge"?

[@JoernLoviscach]

Wartbarkeit und Erweiterbarkeit. So kann man sich später entschließen, zum Beispiel in set und get Umrechnungen einzubauen, die verborgene Variable sogar wegzulassen und/oder im set Checks einzubauen (ggf. auch nur in Kindklassen).