Настройки загрузки - лучшие практики

Я нахожусь в точке своего первого реального приложения, где я добавляю в пользовательские настройки. Я использую Java и очень OO (и пытаюсь сохранить его таким образом), вот мои идеи:

Загрузите все в main() и передайте все "вниз по линии" на требуемые объекты (массив)
То же, что и выше, но просто передайте объект, содержащий данные вниз строка
Загрузите каждую отдельную настройку в качестве необходимых в различных классах.

Я понимаю некоторые основные плюсы и минусы каждого метода (т.е. время и размер), но я ищу некоторые внешние данные о том, какие методы они успешно использовали в прошлом.

Ответ 1

Так как конфигурация/настройки обычно загружаются один раз (при запуске или, возможно, несколько раз во время выполнения программы. В любом случае мы не говорим о очень частом/трудоемком процессе), я бы предпочел простоту эффективность.

Это исключает номер опции (3). Конфигурационная загрузка будет разбросана повсюду.

Я не совсем уверен, в чем разница между (1) и (2) в вашем списке. Имеет ли (1) "прохождение секретных параметров" и (2) означает "передача объекта, содержащего всю конфигурацию"? Если это так, я бы предпочел (2) более (1).

Эмпирическое правило заключается в том, что вы должны держать вещи простыми и сконцентрированными. Преимущество конфигурации чтения в одном месте состоит в том, что он дает вам лучший контроль в случае, если источник конфигурации изменится в какой-то момент.

Ответ 2

Кто-то должен отстаивать предполагаемый стандарт Java, API настроек... и это последнее воплощение в JDK6. Отредактировано для добавления, так как автор, похоже, подкован XML, это больше чем раньше. Думаю, я верю, что вы можете работать с XML juju с Properties, если дух возьмет вас.

Относительно SO: API предпочтений по сравнению с решением Apache, Является ли класс основных предпочтений хорошей идеей?

(хорошо, что обо всем стоящем я готов сделать.)

Ответ 3

Используйте класс SettingsManager или что-то подобное, которое используется для абстрактного получения всех данных настроек. В каждой точке кода, где вам нужен параметр, вы запрашиваете класс SettingsManager - что-то вроде:

int timeout = SettingsManager.GetSetting("TimeoutSetting");

Затем вы делегируете всю логику того, как настройки выбираются для этого одного класса менеджера, реализация которого вы можете изменить/оптимизировать по мере необходимости. Например, вы можете реализовать SettingsManager для извлечения настроек из файла конфигурации или базы данных или какого-либо другого хранилища данных, периодически обновлять настройки, обрабатывать кеширование параметров, которые дорого извлекаются, и т.д. Код с использованием настроек остается блаженно не осознавая всех этих решений по внедрению.

Для максимальной гибкости вы можете использовать интерфейс вместо фактического класса, и у него есть разные администраторы настроек: вы можете менять их в нужное место в какой-то центральной точке, не изменяя базовый код вообще.

В .NET существует довольно богатый набор существующих классов конфигурации (в пространстве имен System.Configuration), которые предоставляют такие вещи, и это работает довольно хорошо.

Я не уверен в эквиваленте Java, но это хороший шаблон.

Ответ 4

Вот учебник по классу свойств. Из Javadocs (Properties):

Класс Properties представляет собой постоянный набор свойств. Свойства можно сохранить в потоке или загруженный из потока. Каждый ключ и его соответствующее значение в свойстве list - строка.

Список свойств может содержать другой список свойств как "умолчания"; это поиск второго списка свойств, если ключ свойства не найден в первоначальный список свойств.

В учебном пособии приведен пример создания экземпляра для типичного использования:

    . . .
// create and load default properties
Properties defaultProps = new Properties();
FileInputStream in = new FileInputStream("defaultProperties");
defaultProps.load(in);
in.close();

// create application properties with default
Properties applicationProps = new Properties(defaultProps);

// now load properties from last invocation
in = new FileInputStream("appProperties");
applicationProps.load(in);
in.close();
. . .

Разумеется, вы могли бы также свернуть свою собственную систему прямо напрямую с помощью файлового хранилища и анализатора XML или YAML. Удачи!

Ответ 5

Недавно мы начали использовать инъекцию зависимостей JSR-330 (используя Guice из SVN) и обнаружили, что можно было прочитать в файле свойств (или любой другой карте) и связать его внутри Guice в модуле в стартовом коде, так что что

@Inject @Named("key") String value

Строка

была введена значением, соответствующим ключу при вызове этого конкретного кода. Это самый элегантный способ, который я когда-либо видел для решения этой проблемы!

Вам не нужно перетаскивать объекты конфигурации вокруг вашего кода или посыпать всевозможные вызовы магических методов в каждом углу кода, чтобы получить значения - вы просто указали на Guice, в котором вы нуждаетесь, и он есть.

Примечание. Я посмотрел на Guice, Weld (Seam-based) и Spring, которые все обеспечивают инъекцию, потому что мы хотим, чтобы JSR-330 был в нашем собственном коде, и мне больше нравится Guice. Я думаю, причина в том, что Guice является самым ясным в своих привязках, в отличие от магии под капотом, происходящей с Weld.