Объектный дизайн игрового плеера

Question

Я поддерживаю сервер для карточной онлайн-игры и, думая о том, чтобы привести его в лучшее состояние, я не смог решить, какая модель объекта подходит для моих нужд.

У меня есть класс Player, который имеет много атрибутов. Первая проблема в том, что класс слишком велик. Вторая проблема заключается в том, что я не знаю, как это сделать. Я перечислю некоторые атрибуты и проблемы с ними.

Некоторые атрибуты очень тесно связаны с игроком: ник, электронная почта, последний логин и т. Д. Они, я полагаю, должны храниться непосредственно в классе игрока и в той же таблице в БД.

Теперь некоторые атрибуты немного сложнее, например, количество денег и золота. Проблема с этим заключается в том, что они исторически хранятся в другой таблице, позже может появиться еще несколько валют и что они ДОЛЖНЫ синхронизироваться в базе данных в своем собственном темпе.

Третья категория атрибутов слабо связана с игроком, например строка состояния, опыт, достижения, статистика и т. Д. Они хранятся в разных таблицах в БД и ДОЛЖНЫ храниться, извлекаться, кэшироваться и синхронизироваться в своем собственном темпе.

Обратите внимание, что одна из больших проблем заключается в том, что нам необходимо реализовать относительно сложные схемы синхронизации баз данных, потому что у нас много онлайн-игроков, и наша игра работает в режиме реального времени, и мы должны максимально снизить нагрузку на БД. .

Мои вопросы:

1. Как определить, какие атрибуты хранить в классе игрока, а какие нет? Скажите, опыт, ник, сумма денег?
2. Когда у кого-то есть атрибуты, которые можно сгруппировать, например (сила, ловкость, выносливость и т. Д.) И (handItem, headItem, footItem, оружие), когда они должны быть сгруппированы, а когда нет?
3. Что делать со сложными схемами синхронизации баз данных? Создать отдельную модель для каждого атрибута, который необходимо синхронизировать независимо, или создать несколько классов DataManager, чтобы разбирать их и работать с ними?
4. Что делать с необходимостью для класса иметь несколько разных «представлений данных» для внешних потребителей? Как XML, Json, еще один XML для некоторого внешнего сервиса, удобочитаемая строка и т. Д.

Извините, если мои вопросы фальшивые, я не очень хорош в ООП-дизайне, я скорее специалист по ФП. И мой английский не очень хорош =).

Answer 1

1. Нет ограничений на то, что вы можете хранить в классе игрока. Пока это касается его и только его, это должно быть в его классе. Но одну вещь, которую вы должны рассмотреть, это сделать несколько классов игроков. Идея такова: если вам это не нужно, не запрашивайте его. У вас могут быть PlayerView_Small, PlayerBuying, PlayerFighting, PlayerSettings (в зависимости от вашей игры они могут не выполнять одну и ту же цель) ... Таким образом, для каждой «потребности» информации об игроке, Вы загружаете только те данные игрока, которые вам нужны, и можете правильно их обрабатывать. Кроме того, вы можете использовать наследование, если один класс является только более подробной версией другого.
2. Если вы говорите о классе, он может относиться к подклассу PlayerAttributes, экземпляр которого содержится в PlayerFighting и PlayerView_Detailed. В базе данных может быть интересно сохранить ее в виде строки (удобно выводимой нашим классом и принятой в конструкторе), чтобы избежать слишком большого количества полей, но вы потеряете способность сортировки . Это, вероятно, не проблема в нашем случае, но может быть в некоторых других.
3. Пусто на данный момент, я не понимаю, где есть синхронизация, будет редактировать, когда будет сообщено.
4. В вашем PlayerViewDetailInfo (или в PlayerAllData в зависимости от того, что вам нужно) вы помещаете некоторые методы, такие как ToXmlClient1(), ToJson(), ToHumanReadableString() (хотя это может немного смущать глаз, вы должны рассмотреть HTML ^^). Класс, имеющий метод, должен быть классом с наименьшими (но достаточными для предоставления ответа) данными. По запросу вы загружаете Player..., который имеет метод, дающий правильный вывод, и записываете его непосредственно в ответ.