对象背后的逻辑重要吗？
在对经典游戏“贪吃蛇”进行基于控制台的 Python 重制的早期阶段时，有人提交了一个补丁以在随机位置生成食物。该代码定义了一个 Food 类，该类运行良好，但其背后的逻辑似乎有点奇怪。
我认为我们应该在食用完食物后将其删除，然后再创建另一份。然而，这个人只是在吃完食物后将食物移动到一个新的随机位置。虽然后者对我来说似乎不合逻辑，但它似乎做了完全相同的事情，甚至可能更有效。
我的问题是：使用前一种逻辑更好，还是后一种逻辑更好，或者我只是在吹毛求疵？
When working on the early stages of a console-based Python remake of the classic game 'Snake', someone submitted a patch to spawn food at random locations. The code defined a Food class which worked fine, but the logic behind it seemed a little weird.
I think we should delete the food once it's been consumed, then create another one. However, this person simply moves the food to a new random location once it's been consumed. While the latter seems illogical to me, it seems to do the exact same thing, maybe even more efficiently.
My question is: Would it be better to use the former logic, or the later, or am I simply nit-picking over nothing?
This all started at: https://bugs.launchpad.net/snakes-game/+bug/628180
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
两者都可以——在某些常识范围内。
后一种方法将节省重新分配对象的时间，因此以这种方式回收它会更有效 - 尽管除非堆碎片是一个问题，但增益可能与您的特定示例无关（例如，在 RAM 非常有限的嵌入式应用程序上） ）。
回收的危险在于，对象可能会保留其先前状态的一些痕迹，因此可能不会以与新对象相同的方式运行 - 在您的情况下，逻辑很简单，因此几乎没有危险，但对于更复杂的对象这可能会变得意义重大。
因此，总的来说，我建议使用“创建一个新对象”方法（它遵循“最小惊喜”原则，并且不太可能使其他参与代码工作的程序员感到困惑），除非存在性能影响（例如在像手机这样的嵌入式应用程序上，您的资源非常有限，并且不想要碎片堆），在这种情况下，“重新使用现有对象”可能是一个明智的解决方案。
Either is fine - within certain common-sense boundaries.
The latter approach will save re-allocating the object, so recycling it in this way will be more efficient - the gain is likely to be irrelevant in your particular example though unless heap fragmentation is a concern (e.g. on an embedded app with very limited RAM).
The danger with recycling is that the object may retain some vestige of its former state, so may not behave in the same manner as a new object would - in your case the logic is simple, so there is little danger, but with more complex objects this could become significant.
So in general I'd suggest the "create a new object" approach (it follows the principle of "least surprise", and will be less likely to confuse other programmers who come to work on the code) unless there are performance implications (e.g. on an embedded application like a phone where you have very limited resources and don't want a fragmented heap), in which case the "re-use an existing object" may be a smart solution.
我相信这两种解决方案都很好。从内存管理的角度来看，将食物重新定位到另一个位置可能不太容易出错，但由于垃圾收集，您不应该太关心这一点。
我认为，虽然实例化一个新的食物对象更符合逻辑，并且更接近现实生活模型，但重新定位更有效。
I believe both solutions are fine. Relocating the food to another location is brobably less error prone in memory management terms, but due to garbage collection, you shouldn't care about that too much.
I'd argue, while instantiating a new food object is more logical, and closer to the real life model, relocating is more efficient.
就 OOP 而言，主要问题并不在于食物是否重新实例化还是重新定位，而是这种行为在对象外部保持透明。游戏引擎应该告诉对象“你已经被吃掉了”之类的信息，但游戏引擎不应该知道对象内部如何处理该信息。如果在内部，该对象维护一个“食物”的单例，并且“消费”方法只是用新值重新形成食物对象，那就没问题。这些都是“食物”实现的内部内容，不应该在该类之外知道。
The main issue as far as OOP is concerned isn't so much whether the food re-instantiates vs. relocates, but rather that this behavior remain transparent outside of the object. The game engine should be telling the object "you've been eaten" and such, but how the object handles that internally shouldn't be known to the game engine. If, internally, the object maintains a singleton of "food" and the "consume" method simply re-forms the food object with new values, that's fine. That's all internal to the implementation of "food" and just shouldn't be known outside of that class.