MooseOOP还是标准Perl？

我将为一个网站编写一些爬虫程序，其想法是该网站将使用一些后端Perl脚本从其他网站获取数据，我的设计（以非常抽象的方式…）将是编写一个包，比如：

package MyApp::Crawler::SiteName

如果站点名称是用于对特定站点进行爬网的模块/包，我显然会有其他包，这些包将在不同的模块之间共享，但在这里并不相关

总之，长话短说，我的问题是：为什么（或者为什么不…）我应该更喜欢Moose而不是标准的OOPerl

---

谢谢，

我从未使用过Moose，但我使用过Catalyst，并且对OO Perl和非OO Perl有丰富的经验。我的经验告诉我，最好的方法是你最舒服的方法

对我来说，这种方法已经变成了“除催化剂之外的任何东西”：（这并不是说爱催化剂并对其发誓的人是错误的——这只是我的品味）

如果你已经有了一个可以构建的爬虫应用程序的核心，那就使用它写的任何东西。如果你是从零开始的，用你最有经验的东西——除非这是你拓展业务并尝试新东西的机会，那么无论如何，在完成任务的同时学习新东西

我认为这只是“哪种语言最好？”的另一个例子，除了个人之外，永远无法回答。这是我昨晚写的东西（在本例中使用）。它的功能、验证和设置应该非常明显。现在想象一下编写等效的原始OO。这并不是非常难，但它确实开始变得更难阅读，不仅仅是代码本身，还有阅读之前或一段时间内没有见过的代码时最重要的部分——意图

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

---

去年，我编写了一个大型测试类，它还使用

handles

功能将大量方法重新修补到底层Selenium/WWWMech对象。消除这种样板文件确实有助于可读性和维护。

您可以在它的文档中找到为什么要使用Moose的答案

Moose的主要目标是使Perl5面向对象编程更容易、更一致，并且不那么单调乏味。有了Moose，你可以更多地思考你想做什么，而更少地思考OOP的机制

---

根据我的经验，也许其他人也会告诉你同样的情况。Moose极大地减少了您的代码大小，它有很多功能和标准功能，如验证、创建对象时强制值、延迟验证、默认值等，非常简单易读，您永远不会想错过Moose。

尽管我不同意Flimzy的介绍(“我没用过驼鹿，但我用过这个用驼鹿的东西”），我同意他的前提

使用你认为可以产生最佳效果的工具。如果（或a）目标是学习如何有效地使用Moose，那么就使用Moose。如果目标是产生好的代码并且学习Moose会分散你的注意力，那么就不要使用Moose

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

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

我发现，自从我开始使用Moose[^1]以来，我对代码“太多”的自然感觉降低了66%。我发现我更容易遵循良好的设计原则，如封装和信息隐藏，因为Moose提供了工具使其更容易。因为Moose自动生成了我通常必须写出的大部分锅炉板（如访问器方法、委托方法等）我发现快速跟上六个月前所做的事情更容易。我还发现，与几年前相比，仅仅为了节省几次击键而编写的代码要简单得多

可以编写干净、健壮、优雅的面向对象Perl，而不使用Moose[^2].根据我的经验，这需要更多的努力和自我控制。我发现，在项目要求我不能使用Moose的情况下，我的常规面向对象代码得益于我从Moose中养成的习惯。我的想法与我用Moose编写代码的想法相同，然后键入三倍于我的代码写下我期望驼鹿能为我带来什么[^3]

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

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

[^2]：宫川的Twiggy代码是我今天刚刚读到的一个很好的例子

---

[^3]：这并不是普遍正确的。有好几个故事是关于人们过度使用Moose提供的工具编写不易维护、可怕的代码。糟糕的程序员可以在任何地方编写糟糕的代码。

当我学习Perl中的对象时，我首先想到的是为什么它如此复杂