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

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

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

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

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

Ответы [ 3 ]

42 голосов
/ 22 августа 2009

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

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

18 голосов
/ 22 августа 2009

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

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

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

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

4 голосов
/ 10 мая 2012

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

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

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

...