我正在尝试使用已编写的Perl API来使用Moose OO系统，但对象之间绝对没有继承，聚合或组合。
除了调试的单个可选角色之外，还没有涉及角色或混合。
据我所知，使用Moose似乎只是增加了大量的复杂性和编译时开销，但收效甚微。
为什么要使用Moose或OO作为一种简单的封装方法，而不是使用更简单的方法将代码打包到Perl模块中？
为了澄清，我完全相信使用Moose正确完整地在Perl中执行OO的许多优点。我只是不明白为什么使用OO作为简单的封装技术？ 我不是在支持Perl OO的主观论点。我希望我在这里使用OO范例时缺少一些优势，我根本就没有看到atm。
This question在Perl中有关于数据封装的一系列优秀观点。注：我不是在讨论强制封装，在这种情况下，系统阻止你查看你不应该去的地方，更多的是关于只暴露一个操作你想要玩的数据的包中的方法。
在这里使用OO是否有一些优势，我错过了？
编辑1：经过一些侦探工作后，我刚刚看到Perl API的作者严重参与了Moose的维护和支持框架。
编辑2：我刚刚看到this question从一个略微不同的角度询问类似的事情。看起来我的回答实际上是“你为什么要首先添加复杂功能？”，特别是考虑到上面编辑2中的信息。
可能的答案
有问题的API似乎只使用Moose OO系统以防止名称空间污染。
通过使用Perl软件包，这也可以做得更充分，正如@amon在下面的评论中指出的那样，使用标准软件包机制可能会很快变得麻烦。 BTW非常感谢所有评论，以帮助澄清我的要求。
答案 0 :(得分：2)
每种情况都是不同的，无论你选择使用Moose还是其他对象框架（或者根本没有），实际上都归结为你计划做的事情和你的要求。
使用Moose编写相关系统可能没有任何直接的优势，但请考虑以下因素：
IOW，使用流行工具有固有的价值。
答案 1 :(得分：1)
不确定它与相关API有关，但似乎没有人提到数据类型 - 这是Moose或Moo的一大好处，具有易于定义和理解（和可重复使用）类型验证和强制属性。