'Statisch schreibgeschützt' vs. 'const'

Question

Ich habe mich über const und static readonly Felder informiert. Wir haben einige Klassen, die nur konstante Werte enthalten. Sie werden für verschiedene Dinge in unserem System verwendet. Daher frage ich mich, ob meine Beobachtung korrekt ist:

Sollten diese Art von konstanten Werten immer static readonly sein für alles, was öffentlich ist? Und nur const für internal/protected/private Werte verwenden?

Was empfehlen Sie? Sollte ich vielleicht sogar keine static readonly Felder verwenden, sondern vielleicht Eigenschaften?

Answer 1

public static readonly Felder sind etwas ungewöhnlich; public static Eigenschaften (mit nur einem get) wären häufiger (vielleicht unterstützt durch ein private static readonly Feld).

const Werte werden direkt in die Aufrufstelle eingebrannt; das hat zwei Seiten:

• es ist nutzlos, wenn der Wert zur Laufzeit abgerufen wird, vielleicht aus der Konfiguration
• wenn Sie den Wert einer Konstanten ändern, müssen alle Clients neu erstellt werden
• aber es kann schneller sein, da ein Methodenaufruf vermieden wird...
• ...der möglicherweise ohnehin vom JIT inline geschaltet wurde

Wenn der Wert sich niemals ändern wird, dann ist const in Ordnung - Zero usw. sind vernünftige Konstanten ;p Ansonsten sind static Eigenschaften häufiger.

Answer 2

Ich würde static readonly verwenden, wenn der Consumer in einer anderen Assembly ist. Wenn const und der Consumer in zwei verschiedenen Assemblies sind, ist das eine gute Möglichkeit, sich selbst ins Bein zu schießen.

Answer 3

Ein paar weitere relevante Punkte, die beachtet werden müssen:

const int a

• muss initialisiert werden.
• Initialisierung muss zur Kompilierzeit erfolgen.

readonly int a

• kann einen Standardwert verwenden, ohne initialisiert zu werden.
• Initialisierung kann zur Ausführungszeit erfolgen (Bearbeitung: nur im Konstruktor).

Answer 4

Dies ist nur eine Ergänzung zu den anderen Antworten. Ich werde sie nicht wiederholen (jetzt vier Jahre später).

Es gibt Situationen, in denen eine const und eine nicht-const unterschiedliche Semantiken haben. Zum Beispiel:

const int y = 42;

static void Main()
{
  short x = 42;
  Console.WriteLine(x.Equals(y));
}

gibt True aus, während:

static readonly int y = 42;

static void Main()
{
  short x = 42;
  Console.WriteLine(x.Equals(y));
}

False ausgibt.

Der Grund dafür ist, dass die Methode x.Equals zwei Überladungen hat, eine, die einen short (System.Int16) und eine, die ein object (System.Object) annimmt. Jetzt stellt sich die Frage, ob eine oder beide mit meinem y-Argument übereinstimmen.

Wenn y ein Kompilierzeitkonstante (Literal) ist, der const-Fall, wird es wichtig, dass eine implizite Konvertierung von int nach short vorhanden ist, vorausgesetzt, dass die int eine Konstante ist und der C#-Compiler überprüft, ob der Wert im Bereich eines short liegt (was bei 42 der Fall ist). Siehe Implizite Konstantenausdruckskonvertierungen in der C#-Sprachspezifikation. Also müssen beide Überladungen berücksichtigt werden. Die Überladung Equals(short) wird bevorzugt (jedes short ist ein object, aber nicht alle object sind short). Daher wird y in ein short konvertiert und diese Überladung verwendet. Dann vergleicht Equals zwei short von identischem Wert, was zu true führt.

Wenn y keine Konstante ist, existiert keine implizite Konvertierung von int nach short. Das liegt daran, dass im Allgemeinen ein int zu groß sein kann, um in ein short zu passen. (Eine explizite Konvertierung existiert, aber ich habe nicht Equals((short)y) gesagt, daher ist das nicht relevant.) Wir sehen, dass nur eine Überladung zutrifft, die Equals(object). Daher wird y in ein object geboxt. Dann vergleicht Equals ein System.Int16 mit einem System.Int32, und da die Laufzeittypen nicht übereinstimmen, ergibt das false.

Wir kommen zu dem Schluss, dass in einigen (seltenen) Fällen die Änderung eines const-Typmembers in ein static readonly Feld (oder umgekehrt, wenn das möglich ist) das Verhalten des Programms ändern kann.

Answer 5

Eines ist zu beachten, const ist auf primitive/Werttypen beschränkt (mit Ausnahme von Zeichenketten).