Zu schwer? 😰 Der Unterschied zwischen Readonly und Const in C#
Вставка
- Опубліковано 15 вер 2024
- Kennst du den entscheidenden Unterschied zwischen const und readonly in C#?
Nein? Kein Problem! 1. Bist du nicht alleine und 2. lernst du alles was du darüber wissen musst in diesem Video :-)
🔥 Hier geht's zu meiner Seite und zu meinen Kursen: codingmitjanni...
#csharp #coding #programmieren
🔥Hier geht's zu meiner Seite und zu meinen Kursen: codingmitjannick.de/s/coding-mit-jannick
Sehr gut erklärt und gezeigt, gerade auch für Anfänger! 🙂 Und dann gibt es auch noch Werte, die nicht zur Kompilierzeit festgelegt werden können. Eine Liste beispielsweise, die nur einmal festgelegt und nie in einem Konstruktor verwendet wird, kann trotzdem nie const sein. Mit dem new-Operator wird eine Instanz der Liste erst zur Laufzeit erstellt. Daher geht hier nur "static readonly", sozusagen als Ersatz. Wenn man dann noch bedenkt, dass man zur List trotz readonly überall im Code mit "Add" Elemente hinzufügen kann, weiß man, warum Programmieren Spaß macht! 😀
Gut zu wissen, bisher hatte ich readonly im Zusammenhang mit DI gesehen.
Ich bin zwiegespalten über dieses Video.
Ja const ist comile-time Konstant und readonly (mehr oder weniger, grob) runtime "Konstant".
Wichtig wäre eine Erklärung wann man const und wann man readonly verwendet.
Performance ist in den meisten Fällen irrelevant, also ignoriere ich das mal.
Im großen und ganzen geht es darum:
Wenn ein Wert immer der gleiche ist. Also unabhängig von der Laufzeit, dann verwendet man const.
PI ist ein tatsächlich gutes Beispiel. PI wird sich auch nicht ändern, wenn man das Program 100 mal ausführt.
Ein Beispiel wären auch Templates für strukturiertes Logging.
Wann verwendet man jetzt readonly?
Dann, wenn sich aus der Sicht der Instanz der Wert nach der Initialisierung nicht mehr ändern darf.
Auch ein gutes Beispiel im Video. Der maximale Wert (wovon auch immer) darf sich nicht ändern. Sonst ergibt es im Kontext der Instanz keinen Sinn.
Bei einer anderen Instanz kann das gut und gerne anders aussehen. Eine Liste zum Beispiel. Die eine darf nur 20 Elemente haben, die andere 100. Aus welchen Gründen auch immer.
Übriges, kleiner (relativ irrelevanter) Hinweis: bei 6:34, das ist kein Setter, das ist technisch gesehen der Konstruktor und darum ist das möglich.
Compile-Zeit, Definition.
Hätte man die CONST Regel nicht einfach ändern können und es im CONSTructor erlauben lassen, warte nein, das geht nicht weil man dann ja nicht mehr statisch darauf zugreifen kann. 🤔 Gibt es dann einen use case für private const, da könnte ich dann einfach private readonly nehmen und hätte funktional das Gleiche? Und genau solche überschneidenden Definitionen finde ich eine unschöne Seite von Programmiersprachen, hab dann immer das Gefühl das ist evolutionäre gewachsen und nicht sauber entworfen. Microsoft Java, 😅 C# hat aber auch viel richtig gemacht.
Ja, das ist ein guter Punkt. Private const wird kaum gebraucht, weil private readonly meistens reicht und flexibler ist.
Weiter so! 🙂
private const double Pi für eine Kreis-Klasse, in der Pi nur intern für die Berechnung des Umfangs genutzt wird. private readonly würde hier für jede Kreis-Instanz eine neue Variable anlegen! Die Abgrenzung ist schon recht klar: Mit const ist es keine typische Variable. Schon bei der Kompilierung werden alle Verweise direkt ersetzt. Daher kannst du auch keinen Breakpoint daran setzen und auch eine Verwendung zur Laufzeit im Konstruktor ist nicht möglich. Verwendest du nur readonly wird zur Laufzeit für jede erzeugte Instanz dieser Wert erneut im Speicher abgelegt. Und mit static readonly wird der Wert zur Laufzeit nur ein Mal im Speicher abgelegt, egal wie viele Instanzen es gibt. Bei jeder Form mit readonly sind es Variablen, Breakpoints und eine Verwendung im (static) Konstruktor sind möglich.
@@MarcelMintken78 Tolle Ergänzung!
@@MarcelMintken78 Also wenn ich Werte habe, die ich mehrmals abrufen aber nie ändern müsste, wären Konstanten besser, zwecks Speicher?
@@m0lDaViA Ja, sowohl beim Speicher als auch bei der Zugriffszeit ist const im Vorteil gegenüber readonly. Meist ist das aber marginal. Bei extrem großen Datenmengen und vielen const könnte das möglicherweise ins Gewicht fallen. Die Wartbarkeit finde ich aber viel wichtiger. Denk an andere, die deinen Code ansehen. Oder an dich selbst, wie du in mehreren Jahren an deinem Code weiterarbeiten möchtest. Readonly impliziert immer, dass das noch irgendwo gesetzt wird. Bei const weißt du, das steht schon vor dem Ausführen fest. Das ist nur da, damit du dich nicht irgendwo vertippst. Das ist nicht mal eine Variable, die zum Programmablauf gehört. Nutzt du nur readonly, ist das ja eine normale Klassenvariable. Die müsste eigentlich im Konstruktor gesetzt werden, weil sie sonst keinen Sinn ergibt. Wenn möglich, also bei nicht veränderbaren Werten und Basistypen, deshalb const nutzen. Je größer und komplexer der Code, desto dankbarer ist man für die korrekte Verwendung. ;-)
Gut erklärt, aber hätte man auch in der Hälfte der Zeit erklären können. Du redest viel um den heissen Brei und wiederholst dich oft.