Где правильно хранить константы? - .NET

Добрый день. Простите за тупой вопрос. Есть константы слудующего вида
1. Используются только в одном классе но в нескольких местах
2. Используются в нескольких классах одной иерархии
3. Используются в нескольких не связанных классах

Как в Си шарп такие представить?

Здравствуйте, Аноним, Вы писали:

А>Добрый день. Простите за тупой вопрос. Есть константы слудующего вида
А>1. Используются только в одном классе но в нескольких местах

Закрытое поле класса.

class MyClass {
  private const string MyConstant = "Hello, Constant";
}

А>2. Используются в нескольких классах одной иерархии

Защищенное поле в базовом классе.

class MyBaseClass {
  protected const string MyProtectedConstant = "Hello, Protected Constant";
}

А>3. Используются в нескольких не связанных классах

Открытое поле в утилитном классе.

class MyUtilityClass {
  public const string MyPublicConstant = "Hello, Public Constant";
}

А>Как в Си шарп такие представить?

Здравствуйте, Аноним, Вы писали:

А>1. Используются только в одном классе но в нескольких местах

Как private const внутри класса.

А>2. Используются в нескольких классах одной иерархии

Как protected const внутри класса.

А>3. Используются в нескольких не связанных классах

Задать const в одном классе (к которому по смыслу ближе это значение), а потом передать как параметр конструктора в другие классы.

Здравствуйте, SergeyT., Вы писали:

ST>Открытое поле в утилитном классе.

ST>

ST>class MyUtilityClass {
ST>  public const string MyPublicConstant = "Hello, Public Constant";
ST>}
ST>

Лучше так:

class MyUtilityClass {
public static string MyPublicConstant = "Hello, Public Constant";
}

... << RSDN@Home 1.2.0 alpha 5 rev. 1536>>

Здравствуйте, Kalina9001, Вы писали:

K>Лучше так:
K>

K>class MyUtilityClass {
K>public static string MyPublicConstant = "Hello, Public Constant";
K>}
K>

Чем лучше?

Здравствуйте, Doc, Вы писали:

А>>3. Используются в нескольких не связанных классах

Doc>Задать const в одном классе (к которому по смыслу ближе это значение), а потом передать как параметр конструктора в другие классы.

А потом долго и нудно дебажить на предмет откуда это значение появилось?
public const и прямое обращение — наше все.

Здравствуйте, Kalina9001, Вы писали:

K>Лучше так:
K>

K>class MyUtilityClass {
K>public static string MyPublicConstant = "Hello, Public Constant";
K>}
K>

Это не константа

const подразумевает static

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Kalina9001, Вы писали:

K>>Лучше так:
K>>

K>>class MyUtilityClass {
K>>public static string MyPublicConstant = "Hello, Public Constant";
K>>}
K>>

А>Чем лучше?

Ничем, это неправильно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Kalina9001, Вы писали:

K>>Лучше так:
K>>

K>>class MyUtilityClass {
K>>public static string MyPublicConstant = "Hello, Public Constant";
K>>}
K>>

А>Чем лучше?

Константы компилятор C# подставляет в код (инлайнит). В случае когда клиентский код скомпилирован с одной версией библиотеки, а выполняется с другой (например через технику bindingRedirect-а), в которой значение константы изменено, то он по прежнему будет использовать старое значение. Поэтому рекомендуется делать видимость констант не шире internal, а в случае когда к константе нужно получать доступ извне сборки — делать static readonly поле.

Здравствуйте, hardcase, Вы писали:

А>>Чем лучше?

H>Константы компилятор C# подставляет в код (инлайнит). В случае когда клиентский код скомпилирован с одной версией библиотеки, а выполняется с другой (например через технику bindingRedirect-а), в которой значение константы изменено, то он по прежнему будет использовать старое значение.

Кэп?

H>Поэтому рекомендуется делать видимость констант не шире internal, а в случае когда к константе нужно получать доступ извне сборки — делать static readonly поле.

Это зависит от требований. Никаких общих рекомендаций тут давать нельзя.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Kalina9001, Вы писали:

K>>>Лучше так:
K>>>

K>>>class MyUtilityClass {
K>>>public static string MyPublicConstant = "Hello, Public Constant";
K>>>}
K>>>

А>>Чем лучше?

H>Константы компилятор C# подставляет в код (инлайнит). В случае когда клиентский код скомпилирован с одной версией библиотеки, а выполняется с другой (например через технику bindingRedirect-а), в которой значение константы изменено, то он по прежнему будет использовать старое значение. Поэтому рекомендуется делать видимость констант не шире internal, а в случае когда к константе нужно получать доступ извне сборки — делать static readonly поле.

Лучше не доводить до такого, либо использовать свойства, а не поля.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, hardcase, Вы писали:

А>>>Чем лучше?

H>>Константы компилятор C# подставляет в код (инлайнит). В случае когда клиентский код скомпилирован с одной версией библиотеки, а выполняется с другой (например через технику bindingRedirect-а), в которой значение константы изменено, то он по прежнему будет использовать старое значение.

А>Кэп?

H>>Поэтому рекомендуется делать видимость констант не шире internal, а в случае когда к константе нужно получать доступ извне сборки — делать static readonly поле.

А>Это зависит от требований. Никаких общих рекомендаций тут давать нельзя.

Можно, например для использования в других сборках — пользуем свойства.

Здравствуйте, vvlad.net, Вы писали:

VN>Лучше не доводить до такого, либо использовать свойства, а не поля.

А нафига для примитивных значений использовать свойства?

Мало того что нужно лишних буков возле объявления понаписать, так еще и руками конструктор статический нарисовать.

Здравствуйте, Аноним, Вы писали:

А>Это зависит от требований. Никаких общих рекомендаций тут давать нельзя.

Требований на объявление констант?

Здравствуйте, hardcase, Вы писали:

А>>Это зависит от требований. Никаких общих рекомендаций тут давать нельзя.

H>Требований на объявление констант?

Истерика? Скажи, например, зачем String.Empty объявлять не-константой? Что такое должно произойти, чтобы это значение изменилось?

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, vvlad.net, Вы писали:

VN>>Лучше не доводить до такого, либо использовать свойства, а не поля.

H>А нафига для примитивных значений использовать свойства?

H>Мало того что нужно лишних буков возле объявления понаписать, так еще и руками конструктор статический нарисовать.

А нафига константы менять? Ну а если константы меняются, то может случиться что значение надо будет получать динамически, что ты тогда будешь делать? Правильно, поставишь свойство. Ну и заодно перекомпиляешь зависимые сборки

Здравствуйте, Аноним, Вы писали:

А>Истерика? Скажи, например, зачем String.Empty объявлять не-константой? Что такое должно произойти, чтобы это значение изменилось?

Бывает так что константы не пустые строки (имена какие-нибудь) — в этом случае вероятность их изменения ой как далека от нуля.

Здравствуйте, hardcase, Вы писали:

А>>Истерика? Скажи, например, зачем String.Empty объявлять не-константой? Что такое должно произойти, чтобы это значение изменилось?

H>Бывает так что константы не пустые строки (имена какие-нибудь) — в этом случае вероятность их изменения ой как далека от нуля.

Молодец, возьми с полки пирожок. Но сначала перечитай, что тебя так рассмешило:

Это зависит от требований.

Здравствуйте, Аноним, Вы писали:

А>А потом долго и нудно дебажить на предмет откуда это значение появилось?
А>public const и прямое обращение — наше все.

Если нудно — то это проблемы архитектуры и именования параметров. Любое значение в приложении должно нести смысл и принадлежать конкретной сущности, а не классу — сборнику констант. Ну и в описанном мной варианте избегаем проблемы появления потенциального God-object, да еще и static по сути.

Здравствуйте, Doc, Вы писали:

Doc>Здравствуйте, Аноним, Вы писали:

А>>А потом долго и нудно дебажить на предмет откуда это значение появилось?
А>>public const и прямое обращение — наше все.

Doc>Если нудно — то это проблемы архитектуры и именования параметров. Любое значение в приложении должно нести смысл и принадлежать конкретной сущности, а не классу — сборнику констант. Ну и в описанном мной варианте избегаем проблемы появления потенциального God-object, да еще и static по сути.

Что такое StringSplitOptions? То что это enum — значения не имеет, но почему он обьявлен отдельно от класса String?

	От:	Аноним
	Дата:	17.01.12 07:19
	Оценка:

От:	SergeyT.	http://sergeyteplyakov.blogspot.com/
Дата:	17.01.12 07:39
Оценка:	+3

От:	Doc	http://andrey.moveax.ru
Дата:	17.01.12 07:41
Оценка:

	От:	Kalina9001
	Дата:	17.01.12 11:35
	Оценка:

	От:	Аноним
	Дата:	17.01.12 11:36
	Оценка:

От:	hardcase	http://nemerle.org
Дата:	17.01.12 11:51
Оценка:	4 (1) +1