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

Question

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

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

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

Answer 1

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

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

(ну, это все, что я хочу сделать, стоя).

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

Список свойств может содержать другой список свойств в качестве своих «значений по умолчанию»;этот второй список свойств ищется, если ключ свойства не найден в исходном списке свойств.

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

    . . .
// 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();
. . .

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

Answer 5

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

@Inject @Named("key") String value

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

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

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