如何用Java编写可靠的Pure Aggregation（组合）游戏对象？
所以我刚开始用Java编写游戏，我正在编写我的游戏对象。 现在我已经在Evolve Your Hierarchy中阅读了你应该将你的游戏构建为组合而不是大类层次结构。 由于上一个链接中的此图像显示：
但是，当实际开始实现时，我有一个关于在哪里应用接口的小问题。
假设你有一个叫做Player的类，接口是Moveable和Renderable。 您是使用公共接口变量实现的：
class Player { public Moveable moveable; public Renderable renderable; } class GenericMoveable implements Moveable { // Function implementations } class PlayerRenderable implements Renderable { // Function implementations } 或者您尝试通过将接口直接应用于对象来执行此操作：
class Player implements Moveable, Renderable { private GenericMoveable genericMoveable; // Non-direct Implementation of Moveable void someMoveFunc(double x, double y) { genericMoveable.someMoveFunc(x, y); } // Direct implementation of Renderable void someRenderableFunction() { // Player class specific code } } class GenericMoveable implements Moveable { // Function implementations }
现在我觉得第二种方法更好。 主要原因是因为我可以创建以下列表：
List renderObjects; // use this to draw all of the objects to the screen List moveObjects; // use this to move all objects at once
我真的只是想确认我是在正确的轨道上。 我很确定在通过Java游戏合成创建游戏对象时，您希望将接口直接应用于相关游戏对象，然后在需要时使用私有接口，并为其余部分直接实现这些function。 它是否正确？ 我正在做的事情的积极和消极是什么？
虽然，虽然我们在这里，但在Java中的Compositional Game Objects的实现中还需要注意什么？ 我该怎么办？ 感谢您提前做出的任何回复，我感谢您的帮助。
这是一个有趣的链接。 我认为你对Player类的想法就是那篇文章所称的组件容器。 为此，将接口应用到类中对我来说就像是要走的路。 它是唯一可以引导您进入纯聚合结构的路径（系统中不再存在Player类本身 。
顺便提一下，您提出的结构基本上是委托设计模式的应用。 Player将委托依赖于Movement对象的所有移动操作，并且它不关心它必须使用哪种特定类型的Movement对象。
我已经使用java创建了一些游戏，并且还看到了一些非常好的游戏的来源，并且似乎最常见的方法是使用第二种方法。 据我所知，使用第二种方法的最佳理由是使用Lists更容易跟踪对象，并允许您使用更少的线条进行绘制。 看起来你走在正确的轨道上，Evolve Your Hierarchy文章对于新游戏开发者来说是一个很好的阅读。