...и понимаю, что ничего хорошего в этом нет, но и лучшего решения не придумывается.
Вот как это выглядит:
Мое чувство прекрасного ущемлено и требует сатисфакции, но ничего лучше не придумывается :(
Проблема в том, что все аргументы обязательные. И когда они передаются в функцию вот так, то компилятор бьет по рукам когда что-то не указано (или указано что-то лишнее). А это полезно, поскольку код все еще активно меняется и параметров становится то больше, то меньше.
Была мысль посмотреть в сторону builder pattern. Но в C++ этот самый builder будет многословным. Плюс к тому придется делать проверки а все ли обязательные параметры заданы (а они все обязательные). Что негативно скажется на объеме builder-а. Посему не вариант.
Видимо, следует объединить несколько аргументов в разные структуры. Скажем, argv_0, python_log_collector, py_config и python_lib_path в одну, а ***_arena, params, shutdown_notificator и ***_interaction_points в другую. Но все равно это будет вести к распуханию вспомогательного кода, причем особой пользы от этого вспомогательного кода на данный момент не будет. Разве что это окажется задел на перспективу.
В общем к чему я это: рекомендации лучших собаководов о том, какой код clean, а какой нет, -- это, конечно, хорошо. Пока не сталкиваешься с суровой реальностью ;) В которой не знаешь как сделать лучше, а тратить время на эстетические изыски не вариант.
Опять выскажу своё мнение. Билдеры переоценены. Их любят в Java по причине отсутствия там аргументов по-умолчанию и именнованых аргументов. Второе, правда, отсутствует и в C++, но, по факту, это единственные причины для билдеров. Читаемость кода они, конечно, улучшают, но билдеры "утяжеляют" кодовую базу. Если вам только не захотелось именнованых аргументов, то я бы с ними не связывался. C++ это не Java.
ОтветитьУдалитьПо моему опыту билдеры очень удобны когда есть 100500 параметров, 99% которых из них имеют значение по умолчанию.
ОтветитьУдалить