Question

在我们的产品中，我们在很多文件的开头都有一个我们需要的大型实用程序文件（do）。不是否有理由将其转换为模块？例如，而不是这样做：

do '../dbi_utilities.pl';
our ($db,$user,$pw,$attr);
my $Data = DBI->connect($db,$user,$pw,$attr) or die "Could not connect to database: $DBI::errstr";

我不能这样做吗？：

use AppUtil;
my $Data = AppUtil->connect();

Answer 1

不这样做的唯一原因是时间。

也就是说，清理界面以及所有调用应用程序都需要时间来使用新界面。

当你开始使用正确的测试（“make test”或“./Build test”或者只是“证明......”）并且能够检查时，你现在花费的时间将会超过你的成本在检查之前你的更改不会破坏任何东西。所以，无论如何，转换。请注意，这不是免费的收获。

Answer 2

通过将代码放入具有适当重构的模块中，可以轻松进行测试。我在我的"Scripts as Modules"文章中讨论了 The Perl Journal 以及关于Perlmonks的"How a Script Becomes a Module"。

祝你好运，

Answer 3

使用do（），您每次都在加载和编译utilities.pl文件，如果多次执行（），可能会导致问题。另外，use在编译时完成，这将使您的程序更快失败，甚至可以使用perl -wc进行测试。

最后，将它保存在一个包中可以保护它的命名空间，这可以在项目增长时提供帮助。

我强烈建议您将utilites.pl转换为加载use的正确Perl包。

Answer 4

制作模块将使其更加强大。现在很多事情都是非正式地依赖于彼此，但这些依赖关系并不是很明显。

此外，它还可以让您只导入部分实用程序。

Answer 5

您可以获得所有酷模块，封装，模块特定功能等。

请注意，使用use语法。为AppUtil命名空间创建一个对象，并调用connect子例程。为您的公用事业。

你也必须有1;在你的文件的末尾。

坚持使用其他方法意味着您不必更改任何代码，最后不必添加1。

所有“do”，“use”和“require”导入，但是其中的范围代码（命名子例程除外导致它们无法隐藏）。

我应该将utilities.pl更改为utilities.pm模块吗？

5 个答案: