“我的世界”服务器的游戏对象结构
我正试图用Ruby编写一个Min克拉夫特服务器，作为一个教育项目，现在我已经到了需要决定如何构造游戏中的对象(实体)的时候了。在我看来，实体是一个游戏中的东西，比如一个块，一个玩家，或者一个骨架。
这是代码评审而不是游戏设计的原因，是因为我对您从一般编程角度对设计的看法感兴趣，因为这是一个开源项目，我希望它尽可能友好地开发人员。
当我开始编写当前的尖峰时，我想出了一些可以用于实体结构的方法。
标准面向对象编程继承
在这个例子中，我会使用标准的OOP类层次结构来设计我的实体。您将有一个基类Entity，它将由Player、Sign、Skeleton进行扩展，您就知道了。它的好处是，它是简单和快速的提出-直到你开始想要分享两个衍生产品的功能。Ruby没有多重继承，所以当我希望Enderdragon实体与Sheep共享一些功能时，它会变得很混乱。它还限制了功能，除非在运行时执行大量的代码复制，如果您想让Villager由Player控制。
模块与继承
这种方法将使用模块共享功能，并在编译时对其进行定义。我们将有一些模块，如Positionable、Orirentable、Nameable和一个基类Entity将在编译时在派生类中定义所有这些(因为缺少一个更好的单词--在Ruby中没有编译)。这样做的好处是，对其他程序员来说，它更“清晰”。Player会有Positionable和RemoteControllable，而Sheep可能有Positionable。这些子类都是在编译时设计的。
模块与元编程
最后，这个方法将利用Factory (或Builder)模式与Modules and Inheritance有类似的方法，但这次它将在运行时定义混合。Entity实例将在运行时重新打开，并在它们的工厂中混合适当的模块。这有巨大的灵活性的好处，而代价也许是稍微违反了POLA。
我现在站在元编程的一边。你认为如何？
module Entity
# The Id of the Entity
attr_accessor :id
def to_s
"Entity <ID:#{id}>"
end
end
module Positionable
attr_accessor :x, :y, :z
end
module Orientable
attr_accessor :yaw, :pitch
end
module Nameable
attr_accessor :name
end
entity = Entity.new
entity.extend(Positionable)
entity.extend(Nameable)
entity.extend(Orientable)
entity.x # => 0f回答 2
Code Review用户
发布于 2014-03-10 12:24:25
我更喜欢你的第二个计划，继承和混合模块。我将重申它们的不同用途，我相信你知道：
- 使用继承来建模对象之间的关系(B是A)。
- 使用混合器来建模行为(C日志，D记住它的位置)。
除非您需要动态添加mixins，否则请应用雅格尼，不要执行它。等待，直到您有一个迫切的动态混合需要，并使用他们只在需要。元编程是一个强大的工具，但它确实使代码更难理解。明智地使用它。
Code Review用户
发布于 2014-03-12 18:51:20
我的爱好之一是木工。当我要开始一个新的项目时，我有一个大致的想法，我将如何去做，只是基于经验。我几乎总是从与Sketchup一起制定计划开始，其中包括我将为每个部分使用的材料。然后，我会仔细考虑我将使用哪一块板(例如，强调、淡化或匹配谷物，尽量减少浪费)，以及我将执行各种操作的顺序。例如，我知道我将连接，刨和锯成正方形的股票，并希望有效地这样做，以节省时间。那时我并没有考虑我将要使用的工具，因为我知道选择通常是显而易见的，如果不是的话，我可以在以后决定。然而，我从未做过的一件事是问自己，我应该在一个项目中使用电动工具还是手动工具，因为我知道我会同时使用这两种工具，无论哪种工具对每个操作都最有效。
我希望大多数人对编码采取类似的方法，这让我怀疑你的问题是否能够或应该得到回答。我不是在质疑它的优点，如果没有别的，它是思考的好食粮。
关于元编程，虽然我们都知道它是什么..停在那儿。我们没有，至少我没有。我们可能同意，与单例类有关的任何事情都可能属于元编程，但是像included和extended、method_missing、alias_method、甚至更低的send之类的钩子呢？此外，虽然元编程的某些用途确实令人心烦意乱，但另一些则非常简单(例如，使用类实例变量而不是类变量)。那么，可以使用什么标准来决定是否应该对特定的问题或一类程序采取元编程方法呢？
元编程的一个缺点是，它使其他程序员很难理解正在发生的事情，因此应该谨慎使用。当元编程既复杂又没有必要时，我倾向于同意这一点。只有“倾向”，因为生活是复杂的。不要忘记我们教书的责任。有时候，这意味着做一些让别人挣扎的事情。假设您已经完成了一些交给我维护的元编程。对元编程知之甚少，我需要一段时间才能弄清楚你做了什么，如果你使用一个不那么复杂的程序，你会花费更多的时间(ww?)接近。然后我有了一个‘啊哈’的时刻，然后想，“现在很酷，真的很酷”，我意识到我可以把同样的方法应用到我正在做的另一个项目上，这样我就可以节省大量的时间，并在交易中给我的同事留下深刻的印象。
https://codereview.stackexchange.com/questions/43917
复制相似问题
腾讯云开发者
