Как можно избежать использования шаблона синглтона в моей игре на основе REST API?

Question

Как можно избежать использования шаблона синглтона в моей игре на основе REST API?

0

Я работаю над небольшой, пошаговой, двухпользовательской игрой, написанной на C++ поверх Cocos2d-x. У меня установлен полный REST API, и я рассматриваю проекты для реализации клиентской стороны.

Когда пользователь открывает игру, ей будет показан список ее активных игр. Этот список должен быть кэширован, но перед отображением списка необходимо выполнить обновление. Всякий раз, когда она набирает одну из игр в этом списке, игра будет загружена. Таким образом, игровые состояния также должны быть кэшированы. Здесь ничего необычного.

Теперь я хотел бы избежать создания url и использования классов cocos2d-x HttpRequest и HttpClient из кода клиента. Более того, код для ведения списка игр, обновления списка, выбор определенного состояния игры и нажатие игрового состояния на сервер может легко вписаться в Singleton. Представьте, что у нас есть такой объект, и мы называем его GameLobby отсутствием лучшего имени.

На мой взгляд, эти связанные действия требуют одного экземпляра класса инкапсуляции, поэтому синглтон, похоже, соответствует счету. Передача ссылки на GameLobby вокруг просто не имеет для меня большого смысла. В основном это означало, что я должен передать его на каждый cocos2d::Scene в моей игре, который должен знать что-либо о состоянии активных игр, получать состояние игры с сервера и т.д. Однако, поскольку я пришел к пониманию, модель Singleton стала более анти-образцовой на протяжении многих лет.

Был бы лучше использовать локатор сервисов? Как насчет других шаблонов - есть ли какие-либо релевантные, которые приходят на ум?

conciliator 08 апр. 2014, в 22:00

Источник

Теги:

c++

rest

design-patterns

singleton

service-locator

1 ответ

Ещё вопросы

conciliator · Accepted Answer · 2014-04-09T07-19-00.000Z

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

Итак, вот быстрая и грязная диаграмма классов того, что я хотел бы реализовать:

GameListScene будет нести ответственность за проведение экземпляра GameList. Это единственная сцена в игре, которая откроет список для пользователя, и поэтому нет текущих требований, в которых говорится, что он должен быть передан. Экземпляр GameScene будет содержать место действия. И GameList и Game будут отвечать за общение с REST API. Одна из моих причин идти с синглтоном заключалась в том, чтобы скрыть URL-адрес и http- GameListScene от клиента (GameListScene и GameScene). Для этого я решил позволить им наследовать RESTClient. Таким образом, я могу сохранить хотя бы скрытый материал http, не повторяя себя.

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