9

这更像是一个用例类型的问题......但也足够通用，可以更广泛地适用：

简而言之，我正在开发一个或多或少是命令行包装器的模块。OO 自然。不涉及太多细节（除非有人想要它们），系统并没有非常复杂，但在这个框架中拥有三四个对象确实感觉很自然。最后，我将把它放在那里，而不是由同一家公司的几个开发人员共同开发的模块。

首先，我使用 Class::Std 实现了 OO，因为 Perl Best Practices (Conway, 2005) 为为什么要使用由内而外的对象提出了很好的论据。完全控制访问哪些属性等等，适当的封装等等。而且他的设计非常简单和聪明。

我喜欢它，但后来注意到没有人真正使用它；事实上，康威本人似乎不再推荐这个了？

所以我搬到了大家最喜欢的Moose。它很容易使用，尽管对于我想要做的事情来说方式太过分了。最大的主要缺点是：它有大量的模块依赖关系，迫使我的模块的用户全部下载它们。一个小缺点是它的功能比我真正需要的要多得多。

什么是建议？强迫其他开发人员使用可能已过时的模块，或者强迫模块的每个用户下载 Moose 及其所有依赖项，给其他开发人员带来不便？

对于流行的适当的 Perl OO 框架，是否有第三种选择，但这两个都没有？

4

5 回答 5

5

公平地说，在 Perl 世界中看到几乎所有有趣的东西都在某个地方依赖 Moose，我不认为它对其他“Perl 开发人员”来说是一个很大的债务。

正如我们所说，他们可能已经安装了它！

编辑：一些统计数据：

Moose 目前在“最依赖”模块列表中排名第 65 位，别名前 100 名，有超过 1637 个软件包依赖它。这几乎和 , 和更多的东西一样Time::HiRes多DBI，而且我认为您不太可能根据这些来提问，对吗？

于 2010-06-12T16:49:10.427 回答
5

目前公认的“现代 Perl OO 框架”是 Moose。我会说让您的用户下载它，或者您可以使用PAR::Packer在安装中将它与您的模块捆绑在一起。

引用“但我不能使用 CPAN ”（...因为我的用户不想安装东西）：

假设您只是在处理您的用户一个 tarball，那么 Module::Install 提供了一个解决方案 - 如果您将脚本放入 script/ 然后执行

install_script(glob 'script/*');
auto_install;

在你的 Makefile.PL 中，'make install' 不仅会将你的脚本放在对你有用的地方，而且'make installdeps' 会调用 cpan（或者如果存在，cpanplus）来为你安装所有缺少的依赖项。

于 2010-06-12T16:56:03.963 回答
4

要添加到现有的好答案...

PBP 中推荐的一些建议并不坏，但 Perl 继续前进。写作时，由内而外的对象是新的热点。现在驼鹿已经吸收了一切。有MooseX::InsideOut，它通过 Class::Std 的完全封装为您提供 Moose 的强大功能，但除非您与没有纪律的程序员一起工作，否则它真的没有必要。

Moose 的那些你现在不需要的功能，你最终会需要它们。即使您不需要所有这些，使用 Moose，您也不必每次需要有趣的功能时都使用和学习 Yet Another OO System。上帝禁止你同时需要两个功能！

于 2010-06-13T00:20:53.137 回答
4

好吧，有Mouse，它与Moose类似，但没有所有依赖项（以及一些功能）。它也启动得更快一些。我自己没有尝试过，但它通常是经过深思熟虑的。

于 2010-06-12T16:42:54.857 回答
0

还有一个 Perl Module Object::InsideOut ，自 2010 年起积极维护。

有点像 Moose 的前身，或者说清楚一点：开发是在 Moose 开始的同时独立开始的，

我知道它存在，但我没有使用它。

于 2011-02-10T15:49:23.770 回答