我正在用Cocos2D-x写一个游戏，我感到挣扎，感觉我的OO很草率。我无法摆脱这种感觉，我可以指出原因。
游戏场景类
图层类
对象类
HUD1
我认为，这些课程对这些课程的依赖程度很高。
我觉得我应该抽象出来并创建一个控制所有这些事件的类，而不是Object，Layer，HUD等中的一些代码。
任何人都可以和我谈谈这是如何制定的，以及我是否犯了OO错误？
答案 0 :(得分：2)
事实证明，尽管在许多OO文本中都是一个例子，但图形和游戏并不适合OO设计。你的本能是关于从数据中取消控制权的。如今，流行的游戏设计模式是拥有组件，实体和系统，而不是严格的OO层次结构。
这个想法是你有实体或游戏对象，它们只是组件的集合，也许还有一些消息传递基础结构。组件存储有关它们所附加的实体的数据，例如，您可能有一个Transform组件和一个velocity组件。现在一种方法是建立一个消息传递系统，组件可以挂钩并使用它来更新数据。例如，Velocity组件可能会挂钩到Update消息，而在Update处理程序中，它可以获取对象的变换并移动它。通过使用消息进行组件之间的所有通信，您可以在很大程度上将它们分离。
系统是处理更新组件数据的不同方式。使用Systems的想法是，您有一个流程可以说“我对具有这些组件的实体进行操作”，然后在运行时获取所有相关实体的列表。这样可以将数据与函数分离得更多，并且可以更轻松地管理线程和依赖性
基本上面向对象的设计是关于在现实世界中捕捉“事物是什么”，但是对于你并不真正想要的游戏，你所关心的只是事物的样子，你希望能够改变某些行为的各个方面没有痛苦。
实体组件系统的良好资源：
http://piemaster.net/2011/07/entity-component-primer/
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/
答案 1 :(得分：0)
在尝试深入研究代码之前，先考虑一下你想要达到的目标（尽管这样做的冲动非常强烈！）
尝试使用依赖注入来解耦您的类。这可能涉及到现在添加一些额外的类和复杂性，但相信我，它将使你的生活更容易，以后你将不可避免地需要重构你的游戏的某些部分。避免使用“口香糖和胶带”解决方案，因为这样做会产生的技术债务会再次出现并且会在以后咬你！