Как лучше всего реализовать публично доступные константы в C#

Question

Как лучше всего реализовать публично доступные константы в C#

Кажется, существует три варианта для реализации публично доступных констант в C#. Мне любопытно, если существуют какие-либо серьезные основания выбрать один по другой или если это - просто вопрос персонального предпочтения.

Выбор 1 - частное поле плюс метод считывания свойства

private const string _someConstant = "string that will never change";

public string SomeConstant
{
    get { return _someConstant; }
}

Выбор 2 - метод считывания свойства только

public string SomeConstant
{
    get { return "string that will never change"; }
}

Выбор 3 - общедоступное поле только

public const string SomeConstant = "string that will never change";

Который Вы рекомендуете и почему?

Обновление

По-видимому, это превратилось в обсуждение того, использовать ли const или static readonly. Не точно, что я предназначил, но это действительно учило меня, что Выбором 3 является определенно плохая идея, потому что, если значение константы изменяется в будущей версии, это требует, чтобы все блоки ссылки были перекомпилированы.

Однако я не думаю, что любой действительно обсудил Выбор 2 все же. Мне все еще любопытно, если существует какой-либо недостаток с наличием только что метода считывания, который возвращает значение и ничто иное.

8

c# constants

задан devuxer 26 February 2015 в 23:17

6 ответов

Если бы я мог проголосовать - я бы проголосовал за ответ Джона Скита. Чтобы добавить к этому, ваши №1 и №2 в точности идентичны, как показано здесь в IL:

.method public hidebysig specialname instance string 
    get_SomeConstant() cil managed
{
  // Code size       11 (0xb)
  .maxstack  1
  .locals init ([0] string CS$1$0000)
  IL_0000:  nop
  IL_0001:  ldstr      "string that will never change"
  IL_0006:  stloc.0
  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end of method Class1::get_SomeConstant

Вариант №2:

.method public hidebysig specialname instance string 
    get_SomeConstant() cil managed
{
  // Code size       11 (0xb)
  .maxstack  1
  .locals init ([0] string CS$1$0000)
  IL_0000:  nop
  IL_0001:  ldstr      "string that will never change"
  IL_0006:  stloc.0
  IL_0007:  br.s       IL_0009
  IL_0009:  ldloc.0
  IL_000a:  ret
} // end of method Class2::get_SomeConstant

Теперь рассмотрим вариант №3. Номер 3 сильно отличается от №1 и №2. Причина этого в том, что, как указывалось ранее, № 3 статичен, поскольку const статичен. Теперь реальный вопрос заключается в том, чтобы сравнить яблоки с яблоками в том, что, если №1 и №2, где статические аксессоры? Тогда они были бы более сопоставимы с №3. В настоящее время вам необходимо инициализировать класс для вариантов 1 и 2, но не для № 3. Таким образом, в этом случае происходит ненужная инициализация объекта, и вы всегда хотите использовать static, когда это возможно, чтобы избежать этого.

Теперь давайте посмотрим на номер 3 в IL:

.field public static literal string SomeConstant = "string that will never change"

Итак, для эффективности я бы использовал номер 3. Этому же меня учили многие талантливые коллеги на протяжении многих лет.

Теперь обратимся к белому слону в комнате. Readonly и const отличаются тем, что cont происходит во время компиляции, а readonly происходит во время выполнения. Статический только для чтения инициализируется один раз, а нестатический только для чтения инициализируется один раз для каждого экземпляра. Если, например, вы задаете свой вопрос, чтобы сделать что-то вроде создания класса константных строк для сообщений об ошибках, которые никогда не изменятся, используйте вариант № 3, а не только для чтения, статический или иначе. Подумайте о попытке инициализировать сотни сообщений об ошибках во время выполнения, а не во время компиляции, вы увидите заметную разницу в производительности. Кроме того, поскольку вы четко заявляете, что это «строка, которая никогда не изменится», только чтение не следует даже рассматривать в этом случае, потому что «... она никогда не изменится».Const и ReadOnly имеют свои места, но readonly не предназначен для элементов, которые никогда не изменятся и известны во время компиляции.

1