这更像是一个用例类型的问题......但也足够通用，可以更广泛地应用：
简而言之，我正在开发一个或多或少是命令行包装器的模块; OO自然而然。没有太多细节（除非有人想要它们），系统没有疯狂的复杂程度，但在这个框架中有三到四个对象确实很自然。最后，它是一个开源的东西，我将放在那里，而不是一个模块与同一公司的一些开发人员一起工作。
首先，我使用Class :: Std实现了OO，因为Perl Best Practices（Conway，2005）为什么要使用由内到外的对象做出了很好的论据。完全控制访问哪些属性等等，适当的封装等。此外，他的设计非常简单和聪明。
我喜欢它，但后来注意到没有人真正使用它;事实上，康威自己似乎不再推荐这个了吗？
所以我感动了每个人的最爱，穆斯。它很容易使用，虽然方式过度杀戮功能明智的我想做什么。主要的重大缺点是：它有一大堆模块依赖，迫使我的模块用户全部下载。一个小小的缺点是它的功能比我真正需要的更多。
有什么建议？不方便开发人员强迫他们使用可能过时的模块，或强迫模块的每个用户下载Moose及其所有依赖项？
是否有适当的Perl OO框架的第三种选择，但这两种框架都不受欢迎？
答案 0 :(得分：5)
完全公平的是，在Perl世界中看到几乎所有有趣的事情都将Moose作为一种依赖关系，我不认为这对其他“Perl开发者”负债。
在我们说话的时候，他们已经安装了它！
编辑：一些统计数据：
Moose目前在“最依赖”模块列表Aliases top 100上排名第65位，超过1637个包依赖它。这几乎和Time::HiRes之类的东西一样多，而且超过DBI，我不认为你会根据那些问题提出质疑吗？
答案 1 :(得分：5)
目前接受的“现代Perl OO框架”是Moose。我会说让你的用户下载它，或者你可以使用PAR::Packer在安装中将它与你的模块捆绑在一起。
引自“But I can't use CPAN”（...因为我的用户不想安装内容）：
假设您只是在处理用户tarball，那么Module :: Install提供了一个解决方案 - 如果您将脚本放入脚本/然后执行
install_script(glob 'script/*'); auto_install;在你的Makefile.PL中，不仅'make install'将你的脚本放在某个对你有用的地方，但'make installdeps'将调用cpan（或者如果存在，cpanplus）为你安装所有缺少的依赖项。
答案 2 :(得分：4)
嗯，有Mouse，就像Moose但没有所有依赖项（以及一些功能）。它也开始加快一点。我自己没有尝试过，但通常是well thought of。
答案 3 :(得分：4)
添加现有的精美答案......
PBP推荐的一些建议并不错，但Perl继续前进。编写时，内外对象是新的热点。现在，穆斯吸收了所有人。有MooseX::InsideOut赋予你Moose的强大功能以及Class :: Std的完全封装，但除非你与没有纪律的程序员一起工作，否则它真的没有必要。
你现在不需要Moose的那些功能，你最终会需要它们。即使你不需要所有这些，使用Moose，每次你需要一个有趣的功能时，你将不必使用和学习另一个OO系统。上帝禁止你在同一时间需要两个功能！
答案 4 :(得分：0)
还有一个Perl Module Object :: InsideOut，自2010年起积极维护。
Moose的前身，或者说明确：开发是在Moose开始的同时独立开始的，
我知道它存在，但我没有使用它。