Правильный способ использовать Константы Globals
Почти в каждом проекте я не могу выбрать, как иметь дело с определенными глобальными постоянными величинами. В более старые дни, когда я записал программы C++, которые не сделали используемого dll's, это было легко. Просто создайте и.h файл со многими const это описало определенные постоянные величины для моего проекта. Затем у меня был каждый файл, включают его, и ta-da! Это работало. Чистый, соблюл принцип DRY и был прост.
Теперь моими проектами является .NET C#, который дает мне большой спектр опций иметь дело с этой проблемой. Из того, что я знаю:
Создайте блок, чей только цель состоит в том, чтобы содержать постоянные величины для моего проекта. Любой блок должен затем сослаться на этого. Я уважаю DRY и KISS, так как добавляющие ссылки достаточно просты. Основная проблема здесь состоит в том, что я должен был бы перекомпилировать целый источник для обновления тех значений.
Используйте app.config файл и имейте все другие блоки, получают константу во время инициализации. Таким образом, я добавляю издержки необходимости инициализировать все только для доступа к глобальному значению. Является более гибким, но также и более болезненным.
Используйте ресурсы. Я думаю, что это совпадает с с app.config.
Так, я знаю, что существует лучший способ сделать это объявление констант. Но я не знаю и, до сих пор, не мог найти, как сделать это. Можно ли помочь? У меня есть леденец!
Спасибо все
9 ответов
Если вы хотите, чтобы значения можно было изменять во время выполнения, используйте app.config.
Если вы хотите, чтобы они были исправлены во время выполнения, вам придется (и вы захотите, чтобы пользователи не возились с ними) перекомпилировать каждый раз, когда вы хотите их изменить, поэтому используйте то, что подходит для вашего языка. В случае C # это какой-то класс / сборка GlobalValues.
Не используйте файл ресурсов для глобальных значений или настроек, если вы не хотите менять местами наборы значений как группу (например, при компиляции для другого языка).
Эээ, если предположить, что ваши константы не огромны, вы должны просто иметь возможность объявить их как public const в выбранном вами классе:
namespace MyProject
{
public class Awesome
{
public const int SomewhatAwesome = 1;
public const int ExtraAwesome = 2;
/* etc */
}
}
Вы должны включить свою const в классах, к которым они относятся, т. Е. Если SomewhatAwesome и ExtraAwesome используются для и классом Awesome , то они должны быть константами, объявленными в этот класс. Не создавайте дополнительную сборку только для хранения значений констант, и не не создавайте выделенный статический класс или пространство имен для ваших констант, если на самом деле нет ничего другого, что группирует константы вместе. .
Файл app.config предназначен для настроек, которые могут быть изменены конечным пользователем во время выполнения. Не помещайте в этот файл константы, которые не должны изменяться. Ресурсы предназначены для «больших» объектов, таких как текстовые файлы и изображения, которые было бы утомительно или невозможно включить в качестве буквальных членов класса. Не помещайте в ресурсы простые вещи, такие как целые числа и короткие строки.
Вы можете использовать ключевое слово readonly вместо const , чтобы избежать необходимости перекомпилировать все при изменении значений.
Выдержка из MSDN:
Хотя константное поле - это время компиляции константа, поле только для чтения может быть используется для констант времени выполнения
См. эту ссылку для получения более подробной информации.
У меня есть несколько проектов, над которыми я работаю на работе, и мы решили создать статический класс для наших глобальных значений и функций:
namespace MyNamespace
{
public static class MyGlobalClass
{
//Global stuff here
}
}
Таким образом, все глобальные элементы всегда будут видны, и вам не нужно создавать экземпляр класса, чтобы использовать их.
Я думаю, что основная проблема здесь заключается в попытке навязать образ мышления C в проекте C #. Если у вас есть набор констант, которые вы просто хотите добавить в файл, я бы воспринял это как знак того, что вам нужно переосмыслить свой дизайн. Уделите время тому, чтобы подумать, к какому классу должна принадлежать каждая константа, и поместите ее туда.
При этом я действительно не думаю, что вы должны обращаться с этими константами иначе, чем с другими данными, они должны находиться в dll. Это также имеет дополнительное преимущество, заключающееся в возможности версии dll в случае изменения «констант».
постоянные времени компиляции меняются в зависимости от вселенной, в которой вы живете. Итак, pi и e - это постоянные времени компиляции.
Константы времени выполнения потенциально могут изменяться с каждой новой версией.
настройки потенциально могут изменяться каждый раз при запуске приложения (или чаще в зависимости от того, как реализованы настройки, например, диск БД, управляемый файл конфигурации и т. Д.).
Похоже, использование класса - это рекомендация Microsoft. http://msdn.microsoft.com/en-us/library/bb397677.aspx
Для проектов C #, если вам нужны константы, возможно, лучше всего использовать файл настроек, предоставленный в Visual Studio в настройках вашего проекта. Он поддерживает настраиваемые типы и AFAIK все, что помечено как сериализуемое.
Как говорили мне многие разработчики, не изобретайте велосипед. Существует два типа настроек: пользовательские настройки и настройки приложения, главное отличие в том, что настройки приложения доступны только для чтения во время выполнения. По сути, это то, что вы хотите, похоже.
Старайтесь избегать классов God и статических «вспомогательных» классов, если можете. Вы должны изо всех сил стараться переместить постоянные данные в соответствующие классы.
Я предполагаю, что, поскольку вы используете C #, вы хотите разрабатывать правильные объектно-ориентированные проекты, принципы и шаблоны. Помните, что объекты - это поведение, а не обязательно функциональность. На мой взгляд, функциональное мышление приводит к созданию процедурного кода.
Вы можете использовать шаблон Singleton, когда данные используются во многих объектах. Хотя это не обязательно лучшая практика. В последнее время я начал больше использовать внедрение зависимостей IoC в этих ситуациях с Unity и MEF.