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

Здравствуйте, Аноним, Вы писали:

А>В общем, как-то само собой, как отражение объективной реальности, появилось в коде такое чудо.
А>Объективная реальность следующая: класс, инкапсулирующий узлы XML. Некоторые узлы содержат достаточно большое количество различных аттрибутов (большинство из которых являются опциями, задающими поведение или настройки). Ну и, получилось в итоге как-то громоздко и не очень красиво. Просьба покритиковать такое решение, и какие есть альтернативные варианты?

вынести настройки в отдельный класс с публичными полями?
дефаултовый конструктор заполняет поля значениями по умолчанию а по мере чтения изменяет их.

Здравствуйте, Аноним, Вы писали:


А>какие есть альтернативные варианты?
Самое очевидное — отдельный класс для работы с аттрибутами-настройками, экземпляр которого и отдается в конструктор.

Здравствуйте, Аноним, Вы писали:

А>В общем, как-то само собой, как отражение объективной реальности, появилось в коде такое чудо.
А>Объективная реальность следующая: класс, инкапсулирующий узлы XML. Некоторые узлы содержат достаточно большое количество различных аттрибутов (большинство из которых являются опциями, задающими поведение или настройки). Ну и, получилось в итоге как-то громоздко и не очень красиво. Просьба покритиковать такое решение, и какие есть альтернативные варианты?

Ну я бы массив сделал.
Поскольку атрибуты скорее всего имеют один и тот же тип (строку).
И не важно, что потом они превращаются (например) в энумы.
Это можно сделать уже внутри конструктора.

Здравствуйте, Аноним, Вы писали:

А>В общем, как-то само собой, как отражение объективной реальности, появилось в коде такое чудо.
А>Объективная реальность следующая: класс, инкапсулирующий узлы XML. Некоторые узлы содержат достаточно большое количество различных аттрибутов (большинство из которых являются опциями, задающими поведение или настройки). Ну и, получилось в итоге как-то громоздко и не очень красиво. Просьба покритиковать такое решение, и какие есть альтернативные варианты?

Мой опыт отражения объективной реальности показывает, что с течением времени атрибуты у объектов имеют свойство исчезать и появляться в новых версиях XML-файлов. Готовы ли вы поддерживать каждое такое изменение в конструкторе класса?

Мне нравится такой синтаксис:

XMLElem oElem("something");

oElem.SetAttibute("asdf",   "ghjk")
     .SetAttibute("qwerty", "uiop")
     .SetAttibute("zxcv",   "bnm");

Здравствуйте, Аноним, Вы писали:

А>В общем, как-то само собой, как отражение объективной реальности, появилось в коде такое чудо.
А>Объективная реальность следующая: класс, инкапсулирующий узлы XML. Некоторые узлы содержат достаточно большое количество различных аттрибутов (большинство из которых являются опциями, задающими поведение или настройки). Ну и, получилось в итоге как-то громоздко и не очень красиво. Просьба покритиковать такое решение, и какие есть альтернативные варианты?

boost::property_tree

Здравствуйте, Аноним, Вы писали:

А>В общем, как-то само собой, как отражение объективной реальности, появилось в коде такое чудо.

Наверняка часть из из этих параметров не являются обязательными, так? Я в этом случае в конструкторе оставляю только обязательные параметры. А для остальных предоставляю набор сеттеров, позволяющих делать инициализацию по принципу конвейера:

  phone_book.add_record(Record(id).set_name(name).set_phone(phone).set_email(email));