Які шаблони дизайну можна застосувати до проблеми налаштувань конфігурації?

У великих та складних програмних продуктах управління налаштовуваними налаштуваннями стає основною проблемою. Два підходи, які я бачив до проблеми:

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

Ці підходи мені здаються неправильними.

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

Я вважаю за краще створювати інтерфейс для встановлення запитів, завантаження та збереження. Використовуючи ін’єкцію залежностей, я можу вводити це в кожен компонент, який цього потребує.

Це забезпечує гнучкість щодо заміни стратегії конфігурації та дає загальну основу для роботи всього. Я віддаю перевагу цьому одному глобальному "завантажувачу налаштувань" (ваш варіант 2), тим більше, що я можу замінити механізм конфігурації для одного компонента, якщо мені це обов’язково потрібно.

В даний час я працюю в системі, де конфігурацією керує один глобальний одиночний об'єкт, який зберігає карту ключів конфігурації до значень. Загалом, хотілося б, щоб це не було зроблено таким чином, оскільки це може спричинити вузькі місця у системі, а також неакуратно для модульного тестування тощо.

Я думаю, що Рід Копсі має на це право (я проголосував за нього), але я точно рекомендую прочитати чудову статтю Мартіна Фаулера про введення залежності:

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

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

Як щодо цього. Ви визначаєте інтерфейс, який можна налаштувати, за допомогою одного методу configure (конфігурації). Аргумент конфігурації - це просто хеш-таблиця, яка пов'язує імена параметрів конфігурації з їх значеннями.

Кореневі об’єкти можуть створювати хеш-таблицю конфігурації будь-яким способом (наприклад: читання її з конфігураційного файлу). Ця хеш-таблиця може містити параметри конфігурації кореневого об'єкта iselft, а також будь-який параметр, який може використовувати один із його компонентів, підкомпонентів, підкомпонентів (тощо).

Потім кореневий об’єкт викликає configure (конфігурацію) для всіх його конфігуруваних компонентів.

Ви можете створити багаторазову реалізацію інтерфейсу, який визначає завантажувач конфігурації. В основному шаблон стратегії, де ви можете визначити один базовий інтерфейс як configLoader, а потім інші різні реалізації, такі як FileSystemLoader, ClasspathLoader, EnvVariablesLoader тощо. Детальніше за цим посиланням