perl - 为什么将 Perl OO 简单地用作数据封装技术？

Question

我正在尝试使用为使用 Moose OO 系统而编写的 Perl API，但对象之间绝对不涉及继承、聚合或组合。

而且，除了用于调试的单个可选角色之外，也没有涉及任何角色或混合。

就我目前所见，使用 Moose 似乎只是增加了大量的复杂性和编译时开销，而 yield 却很小。

为什么要使用 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 在下面的评论中指出的那样，使用标准包机制很快就会变得很麻烦。顺便说一句，非常感谢所有评论，以帮助澄清我的要求。

Answer 1

每种情况都是不同的，您是否选择使用 Moose 或其他对象框架(或根本不使用)实际上取决于您打算做什么以及您的要求是什么。

使用 Moose 编写有问题的系统可能没有任何直接优势，但请考虑以下几点:

您可以免费访问 Moose 的元对象系统，因此您可以以明确定义的方式询问对象以获取有用信息

您可以使用 Moose 的继承系统扩展提供的类；所以即使他们自己不使用继承，如果需要，框架已经到位，您可以这样做

您可以放心，因为您知道该系统是建立在最广泛部署和经过良好测试的 Perl 对象框架之上的。

人们知道 Moose，这意味着如果出现问题，则更有可能获得问题的答案。

IOW，使用流行工具具有内在值(value)。