6

私たちの製品には、多くのファイルの先頭に必要な大きなユーティリティ ファイルがあり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();
4

5 に答える 5

8

これをしない唯一の理由は時間です。

つまり、インターフェイスをクリーンアップし、すべての呼び出し元アプリが新しいインターフェイスを使用するには時間がかかります。

適切なテスト ("make test" または "./Build test" または単に "prove ...") を使用し始めて、変更を確認できるようになれば、時間内にコストがかかることはほとんどありません。チェックインする前に何かを壊すことはありません。無料で稼げるものではないことに注意してください。

于 2008-10-08T20:40:26.760 に答える
7

コードを適切なリファクタリングでモジュールにすることで、テストが容易になります。これについては、Perl Journal の記事「モジュールとしてのスクリプト」と、Perlmonksの「スクリプトがモジュールになる方法」で説明しています。

幸運を、

于 2008-10-08T21:49:27.043 に答える
6

do() を使用すると、utilities.pl ファイルを毎回読み込んでコンパイルすることになるため、do() を複数回実行すると問題が発生する可能性があります。また、useコンパイル時に行われるため、プログラムがより早く失敗したり、perl -wc.

最後に、パッケージに保持することで名前空間を保護できるため、プロジェクトが大きくなるにつれて役立ちます。

utilites.pl を適切な Perl パッケージに変換し、.pl をロードすることを強くお勧めしますuse。

于 2008-10-08T20:20:40.950 に答える
2

それからモジュールを作成すると、より堅牢になります。現在、多くのものが非公式に相互に依存していますが、それらの依存関係はすぐにはわかりません。

また、ユーティリティの一部のみをインポートできるようになります。

于 2008-10-08T20:20:31.747 に答える
1

クールなモジュール、カプセル化、モジュール固有の機能などをすべて利用できます。

useただし、構文で使用することに注意してください。AppUtil名前空間のオブジェクトを作成し、接続サブルーチンを呼び出します。あなたのユーティリティのために。

また、1が必要です。ファイルの最後に。

他の方法に固執するということは、コードを変更する必要がなく、最後に1を追加する必要がないことを意味します。

すべての"do"、 "use"、および "require"がインポートされますが、それらの中にあるスコープコード（名前付きサブルーチンを除いて、それらを非表示にすることはできません）。

于 2008-10-08T20:23:32.600 に答える