【问题标题】:How can I avoid using the singleton pattern in my REST API-based game?如何避免在基于 REST API 的游戏中使用单例模式?
【发布时间】:2014-05-21 17:33:43
【问题描述】:

我正在开发一款基于 Cocos2d-x 的 C++ 编写的小型回合制两人游戏。我已经建立了完整的 REST API,并且正在研究实现客户端的设计。

当用户打开游戏时,她会看到她当前活跃的游戏列表。此列表应被缓存,但必须在显示列表之前尝试刷新。每当她点击该列表中的一个游戏时,就会加载该游戏。因此,游戏状态也必须被缓存。这里没有什么不寻常的。

现在,我想避免构建 url 并使用来自客户端代码的 cocos2d-x HttpRequestHttpClient 类。此外,用于维护游戏列表、刷新所述列表、获取特定游戏状态以及将游戏状态推送到服务器的代码可以很容易地放入单例中。假设我们有这样一个对象,我们称它为GameLobby,因为没有更好的名字。

在我看来,这些相关的操作需要一个单一的、封装的类实例,所以 Singleton 似乎符合要求。传递对GameLobby 的引用对我来说没有多大意义。这基本上意味着我必须将它传递给我的游戏中的每个cocos2d::Scene,他们需要了解有关活动游戏状态、从服务器获取游戏状态等的任何信息。但是,据我了解,多年来,单例模式已成为一种反模式。

使用服务定位器会更好吗?那么其他模式呢?有什么相关的吗?

【问题讨论】:

    标签: c++ rest design-patterns singleton service-locator


    【解决方案1】:

    睡了一夜好觉后,我突然想到我不想创建一个单片机。不一定因为是单例,重点是单体。让一个类实现所有游戏列表和单个游戏状态事务逻辑感觉像是严重违反了single responsibility principle

    所以,这是我想要实现的快速而肮脏的类图:

    GameListScene 将负责持有一个GameList 实例。这是游戏中唯一向用户公开列表的场景,因此目前没有要求必须传递列表。 GameScene 实例将是动作发生的地方。 GameListGame 都将负责与 REST API 通信。我选择单例的原因之一是向客户端隐藏 url 和 http 内容(GameListSceneGameScene)。为了做到这一点,我决定让他们继承RESTClient。这样,我至少可以在不重复自己的情况下隐藏 http 的内容。

    底线是:我有更多使用这种设计的类,但希望它会被证明更简洁,更易于维护。

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 2019-06-08
      • 1970-01-01
      • 1970-01-01
      • 2018-09-23
      • 1970-01-01
      • 1970-01-01
      • 2015-02-03
      • 1970-01-01
      相关资源
      最近更新 更多