Здравствуйте, Alekzander, Вы писали:

A>Здравствуйте, samius, Вы писали:

A>Я же спросил: "Именно чтения?". Чтобы отделить сериализацию от разбора давно придуманы способы типа SAX или построения DOM.

A>Если совсем просто: для сериализатора "possible_owners" и "wizard,warrior" это просто пара строк ключ-значение. А для класса предмета — это данные, на основе которых он вычисляет bool CanObtain().

A>Я другого не пойму: что вы все с этой сериализацией докопались до меня? Наличие классов Wizard и Warrior — это грубейшая ошибка проектирования, вызванная бездумной, механической, неудачной попыткой следовать принципу "Designing good class hierarchies is all about capturing the semantics of the business domain in the type system", а вопросы при этом задают мне и про сериализацию.

Я пытался понять, где же должен быть расположен "код считывания констрейнтов на оружие", если расположение его в "отдельном хелпере" нарушает "высокоуровневые принципы". Ну и походу выяснил, что вместо расположения кода в хелпере высокоуровневые принципы предпочитают DOM и непрограммистов с редактором ресурсов.
А если взять правильный DOM, правильный редактор ресурсов и правильного непрограммиста, то и программисты с хелперами не нужны. Главное — непрограммисту про DDD не рассказывать.