Moose OOP还是Standard Perl？

Question

我打算为一个网站写一些爬虫，想法是网站将使用一些后端Perl脚本从其他网站获取数据，我的设计(以一种非常抽象的方式..)将会写一个包，比方说：

package MyApp::Crawler::SiteName

网站名称将是一个用于抓取特定网站的模块/包，我显然会有其他包，这些包将在不同的模块之间共享，但在这里并不相关。

总之，长话短说，我的问题是:为什么(或者为什么不...)我应该更喜欢Moose而不是标准的OO Perl吗？

谢谢,

Answer 1

虽然我不同意Flimzy的介绍(“我没有用过Moose，但我用过这个使用Moose的东西”)，但我同意他的前提。

使用你认为可以产生最好效果的东西。如果(或a)目标是学习如何有效地使用Moose，那么使用Moose。如果目标是生成好的代码，并且学习驼鹿会分散的注意力，那么就不要使用驼鹿。

然而，您的问题是开放式的(正如其他人所指出的那样)。没有一个答案会被普遍认为是正确的，否则驼鹿的采用率会高得多，我也不会回答这个问题。我真的只能解释为什么我每次开始一个新项目时都选择使用Moose。

正如Sid引用的Moose文档所述。Moose的核心目标是成为一种更干净、更标准化的方式来完成面向对象的Perl程序员自Perl 5.0发布以来一直在做的事情。它提供了捷径，使做正确的事情比做错误的事情更简单。在我看来，这是标准Perl所缺少的东西。它提供了新的工具来将你的问题抽象成更小更容易解决的问题更简单，它还提供了一个健壮的自省和元编程API，试图规范化从Perl空间(即我过去称为符号表Witchery)攻击Perl内部的beastiary。

自从我开始使用Moose^1以来，我发现我对多少代码是“太多”的本能感觉已经减少了66%。我发现我更容易遵循好的设计原则，比如封装和信息隐藏，因为Moose提供了一些工具来让它变得更容易。因为Moose会自动生成我通常必须写出的大部分样板(例如访问器方法、委托方法和其他类似的东西)，所以我发现更容易快速掌握六个月前所做的事情。与几年前相比，我也发现自己编写的代码不那么复杂，只是为了节省几次击键。

可以编写干净、健壮、优雅的面向对象的Perl而不使用Moose^2。根据我的经验，这需要更多的努力和自我控制。我发现，在项目要求我不能使用Moose的情况下，我的常规面向对象代码受益于我从Moose那里学到的习惯。我思考它的方式与我想用Moose编写它，然后输入三倍于我写下我期望Moose将为我生成的代码的三倍。

所以我使用驼鹿，因为我发现它让我成为更好的程序员，也因为它我写出了更好的程序。如果你不觉得这对你来说也是正确的，那么驼鹿就不是正确的答案。

^1:当我在一个模块中达到大约300行代码时，我就开始考虑我的设计。现在我开始对大约100行感到不安。

^2: Miyagawa在Twiggy中的代码是我今天刚刚读到的一个很好的例子。

^3:这并不是普遍正确的。有几个故事流传开来，人们通过过度使用Moose提供的工具来编写可维护性较差、可怕的代码。糟糕的程序员可以在任何地方编写糟糕的代码。

Answer 2

您可以在文档中找到使用Moose的原因。

驼鹿的主要目标是使Perl5面向对象编程更容易、更一致、更少乏味。使用Moose，您可以更多地考虑您想要做的事情，而不是OOP的机制。

根据我的经验，也许其他人也会告诉你同样的事情。Moose极大地减少了你的代码大小，它有很多功能，只是标准的功能，如验证，强制创建对象的值，惰性验证，默认值等，都是如此简单和可读性，你永远不会想错过Moose。

Answer 3

使用Moose。这是我昨晚写的一些东西(本例中使用Mouse )。它做了什么，它验证了什么，以及它设置了什么，应该是非常明显的。现在想象一下，编写等效的原始OO。这并不是很难，但它确实开始变得更难阅读，不仅是代码本身，还有意图，这可能是阅读你以前或一段时间没有见过的代码时最重要的部分。

has "io" =>
    is => "ro",
    isa => "FileHandle",
    required => 1,
    handles => [qw( sysread )],
    trigger => sub { binmode +shift->{io}, ":bytes" },
    ;

我去年编写了一个很大的测试类，它还使用handles功能将大量方法重新分派到底层的Selenium/WWWMech对象。消除这种样板确实有助于提高可读性和可维护性。