Perlのプログラミングスタイル

私はJavaで作業しているため、基本的にはコーディング中にOOPパラダイムを使用しています。私はPerlで仕事を始めようとしていて、Perl開発者が従うパラダイムは何だろうと思っていました。wikiでは、多くのパラダイムをサポートしていると述べていますが、スクリプト言語であるため、これを理解しているとは思いません。

だから私の質問は、Javaで慣れ親しんだオブジェクト指向パターンはPerlの慣用句ですか？それとも効果的なPerlを書くためにデザインスタイルに大幅な変更が必要ですか？

注：これはPerlを批判する問題ではありません。私は実際にはPerlで作業する必要があり、現在のプログラミング方法がどのように変わるかを理解したいと思います。

Perlの哲学は、「現在実用的なことをする」という哲学になりがちです。OOPを使用する必要がある場合は、そこにあります。すべてのソリューションで必要なわけではなく、単純に「これを実行すると、これからこれを実行する」タイプの問題である場合にOOPコードを書くように強制することは、多くの場合逆効果です。

perlのマルチパラダイムの性質は、非常に機能的な側面を持つシュワルツ変換（Lispでは「装飾、ソート、非装飾」として知られている）などに見られます。手続き型（プログラミングのようなC）と命令型（「これを実行すると、これを実行する」のようなbash）のように、OOPが存在します。

デザインパターンは、一般的な問題の再発する解決策です。それらはすべての言語で存在します。これらのパターンはイディオムと呼ばれることもありますが、これはパターンよりもはるかに単純なことを指す場合もあります。

必要に応じて、古典的なGOF設計パターンの多くをperlに実装できます。 Perlのデザインパターンには、GOFに精通している多くの一般的な名前が付けられます。それらすべてが慣用的なperlである必要はありません。

perlでデザインパターンを探索するときは、Mark Dominusによる「デザインパターン」ではないことに注意してください。

多くの人は、デザインパターンは言語の欠陥だと考えています。その観点では、Perlではイテレーターなどのデザインパターンは不要です。常にではありませんが、頻繁に。

まず、慣用的なperlを記述します。Cをperlで、lispをperlで、javaをperlで記述しないでください。PerlはPerlです。慣用的なperlが処理できるよりも大きな問題があり、より複雑なクラス構造が必要になり始めたら、それらを記述します。「この問題は現在、抽象ファクトリを必要とするようになっています」と認識できるように設計パターンを知ってください。しかし、必要がない場合は、perlで抽象ファクトリを作成しようとすることから始めないでください。

一部のライブラリは、OOPと従来の形式の両方で存在します。関数指向またはオブジェクト指向のCGIインターフェイスを使用する必要があるかを参照してください。ライブラリを使用する方法を尋ねる古いSOの質問。

Perlのパラダイムに対するスタンスはTMTOWTDIです（それを行う方法は複数あります）。これは、多くの人が冗談でPerlを書き込み専用言語と呼ぶ理由の1つです。他の人のスタイルはあなたのスタイルとは完全に異なるかもしれないので、それを読むより書く方がはるかに簡単です。

そうは言っても、OOPは確かにPerlでサポートされています。サードパーティのコードをたくさん使用している場合は、OOPである場合とそうでない場合がありますが、独自のコードの場合は、思い通りにOOPを実行できます。私は実際に最初にPerlでOOPを学びました。最初にC ++を試しましたが、何らかの理由で「クリック」しませんでした。

私も同じ状況で、長い間Javaを使用しています。

Perlに移行したことは衝撃と安心でしたが、私は「Perl Best Practices」という本を使いました。これは非常に役立ち、プログラミング言語の基本的な概念を理解すれば、簡単に理解することができます。

perlでそれを行うには1つ以上の方法があることを覚えておいてください。特定のコードを調べて変更するために数え切れないほどの時間を費やしていますが、結局、単純な構文エラーで仕事が完了します。

Perlでコードの再利用を処理する方法は複数あります。多くの例ではアプローチの違いを明確にしておらず、多くのクラスでは少なくとも2つを使用しています。

OOスタイルをできるだけ使用することをお勧めします。ユーティリティ関数の比較的小さなクラスターを必要とするクラスが少なくとも3つ以上ある場合にのみ、EXPORTERを使用します。

そう：

package Foo; 
use Foo::Util qw(util) ;
use strict ; 

sub foo {
}

sub bar {
}

1; 

package Foo::Bar ;
use Foo ; 
use Foo::Util qw(util) ;
our @ISA = qw(Foo) ; 
use strict ; 

sub bar {
}

1; 

package Foo::Util ; 
use Exporter ; 
our @ISA = qw(Exporter) ; 
our @EXPORT = qw(util) ;
use strict ; 

sub util {
}

1;

私は、OOアプローチとEXPORTERアプローチをコード可用性の2つの異なる次元として視覚化することを好みます。まるで、関数がxまたはy軸から現在のパッケージに入っているかのようです。

上記の例では：

Foo::Barfoo()クラスからメソッドを派生Foo

Foo::Barbar()メソッドを定義して、ポリモーフィックメソッドbar()がクラスから派生しないようにしますFoo

クラスFooとパッケージから（関数ではなく）関数をFoo::Bar受け取りEXPORTEDます（クラスではありません）util()Foo::Util

2つのシステムは複雑に見えますが、非常に実用的です。多重継承をトレースすると、トリッキーに速くなる可能性があります。したがって、コードの可用性の2番目の次元を持つことで、継承ツリーを小さく維持し、管理しやすくすることができます。

一般に、関数がモノリシックで比較的ダムである場合は、EXPORTERを使用します。それ以外の場合は、継承を使用します。ただしEXPORTER、3つまたは4つを超えるパッケージが含まれる可能性がある場合を除いて、まったく使用しないでください。