Какие шаблоны проектирования могут быть применены к проблеме настроек конфигурации?

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

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

Эти подходы мне кажутся неправильными.

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

Ответы

Ответ 1

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

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

Ответ 2

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

Я думаю, что у Рида Копси есть право на это (я проголосовал за него), но я бы определенно рекомендовал прочитать статью Мартина Фаулера об инъекции зависимостей:

http://martinfowler.com/articles/injection.html

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

Ответ 3

Как насчет этого. Вы определяете интерфейс Конфигурируемый с помощью одного метода configure (configuration). Аргумент конфигурации - это просто хэш-таблица, которая связывает имена параметров конфигурации с их значениями.

Корневые объекты могут создавать хэш-таблицу конфигурации любым способом (например: чтение из файла конфигурации). Эта хэш-таблица может содержать параметры конфигурации для корневого объекта iselft плюс любой параметр, который может использовать один из его компонентов, подкомпоненты, под-субкомпоненты (и т.д.).

Затем корневой объект вызывает configure (конфигурацию) для всех своих настраиваемых компонентов.

Ответ 4

Вы можете создать несколько реализаций интерфейса, который определяет загрузчик конфигурации. В основном шаблон стратегии, в котором вы можете определить один базовый интерфейс как configLoader, а затем использовать различные реализации, такие как FileSystemLoader, ClasspathLoader, EnvVariablesLoader и т.д. Подробности по этой ссылке