Используйте файл свойств вместо статических конечных переменных - PullRequest
10 голосов
/ 18 января 2012

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

Редактировать: мне нужно использовать эти значения как в классах Java, так и на страницах xhtml.Ценности не зависят от окружающей среды.Я мог бы скомпилировать проект для установки новых значений - без проблем.

Ответы [ 6 ]

20 голосов
/ 18 января 2012

Ответ зависит ...

  • Поместите материал в файлы свойств, если значения меняются в зависимости от среды выполнения (например, настройки соединения с базой данных, IP-адреса сторонних серверов), или это, вероятно, будет изменяться часто / скоро
  • Предпочитайте использовать константы от enum до static final, где это возможно (избегайте "строкового кода")
  • Найдите существующую библиотеку, которая может иметь то, что вы хотите (например, используйте TimeUnit для преобразования часов в секунды вместо static final int SECONDS_IN_HOUR = 3600;)
  • Что осталось (что, надеюсь, не изменится в ближайшее время), используйте public static final в классе, у которого «большинство владений» над ними
  • Избегайте классов, у которых есть статические методы, которые возвращают константу - это просто раздувание кода
1 голос
/ 18 января 2012

Мой любимый подход заключается в следующем:

public class MyProperties {
private static final String BUNDLE_NAME = "my.package.MyProperties"; //$NON-NLS-1$

private static final ResourceBundle RESOURCE_BUNDLE = ResourceBundle
        .getBundle(BUNDLE_NAME);


private MyProperties() {
}

public static long getLong(String key) {
    String strValue = getString(key);
    long result = -1;
    try {
        result = Long.parseLong(strValue);
    } catch (Exception exc) {
        logger.error(exc.getLocalizedMessage());
    }
    return result;
}

public static int getInteger(String key) {
    String strValue = getString(key);
    int result = -1;
    try {
        result = Integer.parseInt(strValue);
    } catch (Exception exc) {
        logger.error(exc.getLocalizedMessage());
    }
    return result;
}

public static String getString(String key) {
    String returnValue = System.getProperty(key);
    if(returnValue != null && returnValue.length() > 0) {
        if(logger.isDebugEnabled()) {
            logger.debug(key+" assigned by system property");
        }
        return returnValue;
    }
    try {
        returnValue = RESOURCE_BUNDLE.getString(key);
    } catch (MissingResourceException e) {
        returnValue = '!' + key + '!';
    }
    return returnValue;
}
}

Этот простой класс сначала ищет ключ в системных свойствах, а затем в пакете ресурсов.Это означает, что вы можете переопределить настройки свойств с помощью параметров командной строки -Dkey = value.

1 голос
/ 18 января 2012

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

При использовании статических полей final необходимо перекомпилировать источники для использования новых значений.С файлами .properties вам обычно просто нужно перезапустить приложение, которое может сделать системный администратор и т. Д.

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

1 голос
/ 18 января 2012

Да, файл свойств es всегда предпочтителен для конфигурации.Существует несколько способов его прочтения, один из которых - apache commons-configuration.

Если свойства зависят от среды, извлеките их (вне проекта) и задайте путь к ним (например, с помощью -Dconfig.location=..).).Если они не меняются в зависимости от среды, просто поместите файл свойств в путь к классам.

См. мою статью о свойствах, зависящих от окружающей среды.

Затем вы можете иметь держатель static для объекта Properties / Configuration / ... или, если возможно, вводить (при использовании DI-фреймворка) значения везде, где они необходимы.

1 голос
/ 18 января 2012

Оба подхода хороши:

  1. Имеет статический класс с обязательными final полями.

  2. Имейте сингелтон, но сохраняйте его из нескольких потоков соответствующим образом.

  3. если возможно, используйте enum над статическими полями. Таким образом, вы можете группировать связанные поля вместе.

Если это значения уровня приложения, я предпочитаю static класс, а не сингелтон.

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

0 голосов
/ 18 января 2012

Хорошо иметь их в одном месте.Файл свойства или статический класс?Файл свойств должен использоваться, например, для локализации.Статический класс, например, для строковых констант.

...