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

S>>>Можно, но не нужно. Это то место, где у него отношения между монстром, персонажем, оружием, локацией и фазой луны. Если об таком отношении написано в карточке, то в каком классе должно написать код чтения карточки, что бы не нарушить высокоуровневый принцип и у нас нет хелперов?

A>>Именно чтения? В классе сериализатора (например). Естественно, внешнего по отношению к нашему проекту.
S>Могло бы быть отличным ходом, если бы внешний к нашему проекту проект умел бы обращаться с логикой нашего проекта. Но боюсь, если внешний проект начнет понимать, что такое оборотень, палладин и полнолуние, то это будет не такой уж и внешний проект. Внешний проект может дать нам XML, JSON или какое-то другое представление (табличное, например), далекое от сущностей нашего высокоуровневого дизайна. Все еще кому-то надо разобрать токены (или что там) представления карточки

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

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

S>>>Можно, но не нужно. Это то место, где у него отношения между монстром, персонажем, оружием, локацией и фазой луны. Если об таком отношении написано в карточке, то в каком классе должно написать код чтения карточки, что бы не нарушить высокоуровневый принцип и у нас нет хелперов?

A>>Именно чтения? В классе сериализатора (например). Естественно, внешнего по отношению к нашему проекту.
S>Могло бы быть отличным ходом, если бы внешний к нашему проекту проект умел бы обращаться с логикой нашего проекта. Но боюсь, если внешний проект начнет понимать, что такое оборотень, палладин и полнолуние, то это будет не такой уж и внешний проект. Внешний проект может дать нам XML, JSON или какое-то другое представление (табличное, например), далекое от сущностей нашего высокоуровневого дизайна. Все еще кому-то надо разобрать токены (или что там) представления карточки

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

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

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