Moose OOP 还是标准 Perl？

Question

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

package MyApp::Crawler::SiteName

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

无论如何，长话短说，我的问题是：为什么（或者为什么不......）我应该更喜欢 Moose 而不是 Standard OO Perl？

Answer 1

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

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

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

Answer 2

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

对我来说，这种方法已经成为“除了 Catalyst 之外的任何方法”:)（这并不是说那些热爱并信奉 Catalyst 的人是错误的——这只是我的口味）。

如果您已经拥有可以构建的爬虫应用程序的核心，请使用它所编写的任何内容。如果您从头开始，请使用您最有经验的内容 - 除非这是您扩展并尝试的机会一些新的东西，那么无论如何，在学习新东西的同时完成你的任务。

我认为这只是“哪种语言最好？”的另一个例子。除了个人之外，这个问题永远无法回答。

Answer 3

尽管这是 10 年前提出的问题，但 Perl 世界已经发生了很大变化。我想大多数人现在都发现 Moose 并没有实现人们所想象的一切。有几个衍生项目、大量 MooseX 垫片等等。如此多的流失是一些接近有用但不完全有用的代码的味道。甚至原作者 Stevan Little 也在研究它的替代品 Moxie，但它从未真正走向任何地方。我认为没有人对 Moose 完全满意。

目前，无论您对该框架的估计如何，未来可能不是 Moose。我在 Intermediate Perl 中有一个关于 Moose 的章节，但我会在下一版中删除它。这不是质量决定，只是该领域正在发生的事情的实际情况。

Ovid 正在开发 Corrina，这是一个类似但又不同的框架，试图解决一些相同的问题问题。 Ovid 概述了他想要改进的各种内容，因此您可以将此作为您自己决定的基础。无论您对 Moose 或 Corrina 有何看法，我认为社区现在正在摆脱 Moose 阶段。

您可能想听一下 Moose 如何让我成为一名糟糕的 OO 程序员，来自 Tadeusz Sośnierz 的简短演讲，地址： PerlCon 2019。

即使您持怀疑态度，我也会说在您承诺重新配置大型代码库之前在一个小项目中尝试 Moose。然后，在一个中等项目中尝试一下。我倾向于认为像 Moose 这样的框架在适合页面的各种示例中看起来很有吸引力，但直到问题变得更加复杂时才显示出它们的弱点。在您了解更多之前不要全力以赴。

不过，您至少应该了解 Moose 的基础知识，因为您可能会遇到使用它的其他代码。

Perl 5 Porters 甚至可能将这个包含在核心 Perl 中，但是完整的交付可能会在五到十年的范围内发生，即便如此，您也必须坚持使用受支持的 Perl。我遇到的大多数人在 Perl 版本上都落后了大约三到五年。如果你控制你的 perl 版本，那不是问题。但并不是每个人都这样做。坚持等待科琳娜可能不是一个好的短期计划。

Answer 4

当我了解 Perl 中的对象时，我首先想到的是为什么 Perl 通常试图使事情变得简单，但它却如此复杂。

通过 Moose，我发现 Perl 中可以实现简单的 OOP。它在某种程度上使 Perl 的 OOP 回到了可管理的水平。

（是的，我承认，我不喜欢 Perl 的对象设计。）

Answer 5

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

使用您认为可以产生最佳结果的东西。如果（或一个）目标是学习如何有效地使用 Moose，那么使用 Moose。如果目标是编写好的代码，并且学习 Moose 会分散注意力，那么就不要使用 Moose。

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

正如 Sid 从 Moose 文档中引用的那样。 Moose 的核心目标是成为一种更清晰、标准化的方式来完成自 Perl 5.0 发布以来面向对象 Perl 程序员一直在做的事情。它提供了使做正确的事情比做错误的事情更简单的捷径。在我看来，这是标准 Perl 所缺乏的东西。它提供了新的工具，使您的问题更简单地抽象为更小、更容易解决的问题，并且它提供了强大的自省和元编程 API，试图规范化从 Perl 空间侵入 Perl 内部的野兽（即我以前提到的）作为符号表巫术）。

我发现自从我开始使用 Moose[^1] 以来，我对代码量“太多”的自然感觉已经减少了 66%。我发现我更容易遵循良好的设计原则，例如封装和信息隐藏，因为 Moose 提供的工具可以让这一切变得更容易。因为 Moose 自动生成了我通常必须写出的大部分样板文件（例如访问器方法、委托方法和其他此类内容），所以我发现可以更轻松地快速了解我六个月所做的事情前。我还发现自己编写的代码比几年前要少得多，只是为了节省自己敲击几次键盘的次数。

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

所以我使用 Moose，因为我发现它让我成为更好的程序员，并且因为它我写出了更好的程序。如果您不认为这也适合您，那么 Moose 就不是正确的答案。

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

[^2]：Miyakawa 在 Twiggy 中的代码是我今天刚刚读到的一个很好的例子。

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

Answer 6

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

Moose 的主要目标是使 Perl 5 面向对象编程更容易、更一致、更不乏味。使用 Moose，您可以更多地考虑您想要做什么，而不是考虑 OOP 的机制。

根据我的经验，其他人可能也会告诉你同样的事情。 Moose 极大地减少了您的代码大小，它具有很多功能，并且只有标准功能，例如验证、创建对象时强制值、惰性验证、默认值等，这些功能非常简单易读，您将永远不想错过 Moose。