Как сделать объекты в глубине легко настраиваемыми «сверху»?

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

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

class ConfigurationParameterBase
{
public:
ConfigurationParameterBase(ConfigurationService* service,
std::string name)
: service_(service), name_(std::move(name)) {
assert(service_);
service_->registerParameter(this);
}
protected:
~ConfigurationParameterBase() {
service_->unregisterParameter(this);
}

public:
std::string name() const { return name_; }
virtual bool trySet(const std::string& s) = 0;

private:
ConfigurationService* service_;
std::string name_;
};

template<typename T>
class ConfigurationParameter : public ConfigurationParameterBase
{
public:
ConfigurationParameter(ConfigurationService* service,
std::string name, std::function<void(T)> updateCallback = {})
: ConfigurationParameterBase(service, std::move(name))
, value_(boost::none)
, updateCallback_(std::move(updateCallback))
{ }

bool isSet() const { return !!value_; }
T get() const { return *value_; }
T get(const T& _default) const { return isSet() ? get() : _default; }

bool trySet(const std::string& s) override {
if(!fromString<T>(s, value_))
return false;
if(updateCallback_)
updateCallback_(*value_);
return true;
}

private:
boost::optional<T> value_;
std::function<void(T)> updateCallback_;
};

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

Далее у нас есть ConfigurationService, Он отвечает за отслеживание текущей конфигурации и всех наблюдателей. Индивидуальные параметры могут быть установлены с помощью setConfigurationParameter, Здесь мы можем добавить функции для чтения всей конфигурации из файла, базы данных, сети или чего-либо еще.

class ConfigurationService
{
public:
void registerParameter(ConfigurationParameterBase* param) {
// keep track of this observer
params_.insert(param);
// set current configuration value (if one exists)
auto v = values_.find(param->name());
if(v != values_.end())
param->trySet(v->second);
}

void unregisterParameter(ConfigurationParameterBase* param) {
params_.erase(param);
}

void setConfigurationParameter(const std::string& name,
const std::string& value) {
// store setting
values_[name] = value;
// update all 'observers'
for(auto& p : params_) {
if(p->name() == name) {
if(!p->trySet(value))
reportInvalidParameter(name, value);
}
}
}

void readConfigurationFromFile(const std::string& filename) {
// read your file ...
// and for each entry (n,v) do
//    setConfigurationParameter(n, v);
}

protected:
void reportInvalidParameter(const std::string& name,
const std::string& value) {
// report whatever ...
}

private:
std::set<ConfigurationParameterBase*> params_;
std::map<std::string, std::string> values_;
};

Затем мы можем, наконец, определить классы нашего приложения. Каждый член класса (типа T), который должен быть конфигурируемым, заменяется членом ConfigurationParameter<T> и инициализируется в конструкторе с соответствующим именем конфигурации и, при необходимости, обратным вызовом обновления. Затем класс может использовать эти значения, как если бы они были обычными членами класса (например, fillRect(backgroundColor_.get())) и обратные вызовы вызываются при изменении значений. Обратите внимание, как эти обратные вызовы напрямую отображаются на стандартные методы установки класса.

class Button
{
public:
Button(ConfigurationService* service)
: fontSize_(service, "app.fontSize",
[this](int v) { setFontSize(v); })
, buttonText_(service, "app.button.text") {
// ...
}

void setFontSize(int size) { /* ... */ }

private:
ConfigurationParameter<int> fontSize_;
ConfigurationParameter<std::string> buttonText_;
};

class Window
{
public:
Window(ConfigurationService* service)
: backgroundColor_(service, "app.mainWindow.bgColor",
[this](Color c){ setBackgroundColor(c); })
, fontSize_(service, "app.fontSize") {
// ...
button_ = std::make_unique<Button>(service);
}

void setBackgroundColor(Color color) { /* ... */ }

private:
ConfigurationParameter<Color> backgroundColor_;
ConfigurationParameter<int> fontSize_;
std::unique_ptr<Button> button_;
};

Наконец, мы склеиваем все вместе (например, в main). Создать экземпляр ConfigurationService а затем создать все с доступом к нему. При вышеуказанной реализации важно, чтобы service переживает всех наблюдателей, однако это можно легко изменить.

int main()
{
ConfigurationService service;
auto win = std::make_unique<Window>(&service);

service.readConfigurationFromFile("config.ini");

// go into main loop
// change configuration(s) whenever you need
service.setConfigurationParameter("app.fontSize", "12");
}

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

Не стесняйтесь поиграть с вышеуказанным кодом Вот

Позвольте мне быстро подвести итог:

• Здесь нет переплетения классов. Window не нужно ничего знать о конфигурации Button,
• Это правда, что все классы должны иметь доступ к ConfigurationService, но это легко сделать с помощью интерфейса, что делает фактическую реализацию взаимозаменяемой.
• Усилия по реализации посредственны. Единственное, что вам нужно расширить для поддержки большего количества типов конфигурации, это fromString шаблон, но это необходимо в любом случае, если вы хотите анализировать конфигурации из текстовых файлов.
• Конфигурации могут быть для каждого класса (как в примере) или для объекта (просто передать ключ конфигурации или просто префикс в конструктор класса).
• Различные классы / объекты могут подключаться к одной и той же записи конфигурации.
• Конфигурации могут быть предоставлены из произвольных источников. Просто добавьте еще одну функцию (например, loadConfigurationFromDatabase) к ConfigurationService, чтобы сделать это.
• Неизвестные записи конфигурации и / или неожиданные типы могут быть обнаружены и сообщены пользователю, в файле журнала или где-то еще.
• Конфигурация может быть изменена программно, если это необходимо. Добавьте соответствующий метод к ConfigurationService и программно измененная конфигурация может быть записана обратно в файл или базу данных при выходе из программы.
• Конфигурации могут быть изменены во время выполнения (не только при запуске).
• Настраиваемые значения (ConfigurationParameter члены) могут быть использованы с комфортом. Это может быть улучшено дополнительно путем предоставления соответствующего оператора приведения (operator T() const).
• ConfigurationService Экземпляр должен быть передан всем классам, которые должны что-то зарегистрировать. Это можно обойти, используя глобальный или статический экземпляр (например, как Singleton), хотя я не уверен, что это лучше.
• Возможны многие улучшения в отношении производительности и потребления памяти (например, преобразование каждого параметра только один раз). Смотрите выше, как простой набросок.