Лучший способ управления конфигурационным файлом?

Question

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

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

В 2 варианта, которые мы обсуждаем:

1. В конфиг-файле, указать класс-путь класса, который реализует меры, которые необходимо принять (например: «ActionToTake»: " com.company.publish.SendEveryoneAnEmailClass "). Внутри кода, когда это событие встречается, мы можем сделать Class.forName (config.ActionToTake) .newInstance(). Run(), чтобы вызвать указанное действие.

2. В конфиг-файл, указать удобочитаемое-фразу, действие, которое должно быть принято (например: "ActionToTake": "SendEveryoneAnEmail"). Внутри кода, когда это событие встречается, мы можем разобрать config.ActionToTake и выполнить отображение, которое переводит это осуществление действий (например: новый SendEveryoneAnEmailClass() Run().)

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

Обоснование варианта 1: Любой, кто читает конфигурационный файл, явно и сразу узнает, какой класс будет вызван, и где он будет реализован. Это также позволяет реализовать/импортировать класс действия из полностью отдельного JAR-файла без перекомпиляции/изменения нашего кода.

Причина, связанная с вариантом 2: Файл конфигурации должен быть подробным описанием намерения пользователя и не должен содержать сведения о реализации, такие как конкретные имена классов & пути пакетов. Рефакторинг имен классов/пакетов также может быть выполнен без необходимости внесения изменений в файл конфигурации.

Мысли о том, какая из этих двух философий дизайна предпочтительна для конфигурационных файлов?

Answer 1

Преимущество первого варианта заключается в том, что, как заметил Яс, возможность «связывать» код в будущем. Это реальное преимущество только в том случае, если вы продаете/распространяете свое программное обеспечение как закрытый пакет или если вы планируете поведение «горячей замены» на производстве. Вы уже указали на недостатки - рефакторинга

2-й вариант:

• Это не поможет вам рефакторинга. Если вы измените свое действие с SendEmail на BringBeer, но вы оставите строку send email, значит, вы не смогли.
• Читаемость. send-everyone-an-email не хуже SendEveryoneAnEmail. Каждый разработчик будет знать, что произойдет. Его нельзя путать с LaunchRockets. Ваш код может найти класс на основе некоторого текста, не обязательно полного имени. Ваш код может предполагать, что действия находятся в определенном пакете, если явно не указано. И это способ объединить оба варианта.

Рассмотрите также еще одну возможность: выполните конфигурацию в коде. Если вы не хотите перекомпилировать пакет, вы можете использовать язык сценариев (groovy). Он позволяет создавать очень читаемые dsl, и у вас будет рефакторинг.