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

G>То есть у нас появился объект "считыватель карточек Х", где Х — термин предметной области, так? Это ведь уже не совсем ubiquitous language, про который говорит DDD.

Это опять результат того, что я не очень аккуратно написал. Дело не в считывании как таковом, а в том, что связи между "воин" — "визард" — "меч" — "посох" это, с моей точки зрения, ДАННЫЕ. Они должны создаваться отдельным редактором (который я, опять же, неаккуратно назвал "админкой") и загружаться движком. Их должно быть можно менять, не меняя код. Данные такого типа, как я слышал, называют "ресурсы". А хардкодить ресурсы в классах движка (и вообще в коде) можно только от бедности. (Если посмотреть исходники старых игр, они любили БД с игровыми данными пихать прямо в Си в виде файла с дефайнами, но тогда же и железо другое было).

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

Мне вообще всё равно, как устроена сериализация (объект "считыватель карточек Х"), это малозначительный аспект кода. А вот когда я вижу класс Wizard, это для меня сразу красный свет. Кстати, многие в реальности так и проектируют, судя по всему. Например, редактор карт от Heroes 3 не позволяет создавать свои мечи и посохи (у каждого шмота в этой игре есть требования к персонажу, который может им владеть, но оно вообще составное, а некоторые его части — количественные). Он позволяет только выбрать из готовой коллекции и положить в заданное место или снабдить им игрока. Это, конечно, не значит, что сама коллекция у них обязательно прописана в коде. Может, в каком-то файле с данными лежит. Но вот то, что они её не вынесли на уровень редактора, это большая архитектурная ошибка. Мы бы до сих пор играли в Heroes 3... в смысле, ещё больше Была бы куча total conversions. Всё это неплохо окупается по оконцовке.

Если же ты имел в виду просто то, что "карточка персонажа" и "карточка предмета" — не ubiquitous language для RPG, то я не соглашусь. Люди играли в РПГ задолго до компьютеров, и многие настольные версии, насколько я знаю, не просто имели карточки, а карточки там были главными объектами, не считая многогранника ("кубика"). Ещё, насколько я читал, там были "мастера игры" — выделенные люди, которые "я, таки, не играю, я, таки, счёт веду". Может быть (это не точно, надо думать), что даже можно было бы назвать какой-нибудь класс GameMaster — и это тоже был бы ubiquitous language.

G>Продолжаем мысленный эксперимент с софтом для МРТ. Предположим у нас не просто аппарат, а целая система, когда аппарат снимки на сервер сохраняет, а компьютер у врача, возможно совершенно в другому месте, отображает. Так вот по этой логике какой класс должен заниматься сохранением карточек\файлов МРТ на сервере и их считыванием на клиенте?

Класс сторонней библиотеки, разумеется. Называться он будет так, как его назовут разработчики облачного SDK. Даже если ты будешь писать его сам, не надо делать вид, что это всё ещё часть "софта для МРТ".

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

G>То есть у нас появился объект "считыватель карточек Х", где Х — термин предметной области, так? Это ведь уже не совсем ubiquitous language, про который говорит DDD.

Это опять результат того, что я не очень аккуратно написал. Дело не в считывании как таковом, а в том, что связи между "воин" — "визард" — "меч" — "посох" это, с моей точки зрения, ДАННЫЕ. Они должны создаваться отдельным редактором (который я, опять же, неаккуратно назвал "админкой") и загружаться движком. Их должно быть можно менять не-программистам, не меняя код. Данные такого типа, как я слышал, называют "ресурсы". А хардкодить ресурсы в классах движка (и вообще в коде) можно только от бедности. (Если посмотреть исходники старых игр, они любили БД с игровыми данными пихать прямо в Си в виде файла с дефайнами, но тогда же и железо другое было).

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

Мне вообще всё равно, как устроена сериализация (объект "считыватель карточек Х"), это малозначительный аспект кода. А вот когда я вижу класс Wizard, это для меня сразу красный свет. Кстати, многие в реальности так и проектируют, судя по всему. Например, редактор карт от Heroes 3 не позволяет создавать свои мечи и посохи (у каждого шмота в этой игре есть требования к персонажу, который может им владеть, но оно вообще составное, а некоторые его части — количественные). Он позволяет только выбрать из готовой коллекции и положить в заданное место или снабдить им игрока. Это, конечно, не значит, что сама коллекция у них обязательно прописана в коде. Может, в каком-то файле с данными лежит. Но вот то, что они её не вынесли на уровень редактора, это большая архитектурная ошибка. Мы бы до сих пор играли в Heroes 3... в смысле, ещё больше Была бы куча total conversions. Всё это неплохо окупается по оконцовке.

Если же ты имел в виду просто то, что "карточка персонажа" и "карточка предмета" — не ubiquitous language для RPG, то я не соглашусь. Люди играли в РПГ задолго до компьютеров, и многие настольные версии, насколько я знаю, не просто имели карточки, а карточки там были главными объектами, не считая многогранника ("кубика"). Ещё, насколько я читал, там были "мастера игры" — выделенные люди, которые "я, таки, не играю, я, таки, счёт веду". Может быть (это не точно, надо думать), что даже можно было бы назвать какой-нибудь класс GameMaster — и это тоже был бы ubiquitous language.

G>Продолжаем мысленный эксперимент с софтом для МРТ. Предположим у нас не просто аппарат, а целая система, когда аппарат снимки на сервер сохраняет, а компьютер у врача, возможно совершенно в другому месте, отображает. Так вот по этой логике какой класс должен заниматься сохранением карточек\файлов МРТ на сервере и их считыванием на клиенте?

Класс сторонней библиотеки, разумеется. Называться он будет так, как его назовут разработчики облачного SDK. Даже если ты будешь писать его сам, не надо делать вид, что это всё ещё часть "софта для МРТ".