Programmierstil in Perl

Ich arbeite in Java, daher verwende ich beim Codieren grundsätzlich das OOP-Paradigma. Ich bin kurz davor, in Perl zu arbeiten, und habe mich gefragt, welchem ​​Paradigma Perl-Entwickler folgen. Im Wiki wird erwähnt, dass es viele Paradigmen unterstützt, aber ich bin nicht sicher, ob ich das verstehe, da es eine Skriptsprache ist.

Meine Frage lautet also: Sind die objektorientierten Muster, mit denen ich in Java vertraut bin, in Perl idiomatisch, oder muss ich meinen Designstil erheblich ändern, um effektives Perl zu schreiben?

Hinweis: Dies ist keine Frage, um Perl zu kritisieren. Ich muss tatsächlich in Perl arbeiten und möchte verstehen, wie sich die aktuelle Art und Weise, wie ich programmiere, ändern wird.

Perls Philosophie ist in der Regel die, "das zu tun, was jetzt praktisch ist". Wenn Sie OOP verwenden müssen, ist es da. Es ist nicht in allen Lösungen erforderlich, eine Person zum Schreiben von OOP-Code zu zwingen, wenn es sich um ein einfaches Problem vom Typ "Tun Sie dies, dann dies, dann" handelt, das häufig kontraproduktiv ist.

Die Multi-Paradigmen-Natur von Perl kann in Dingen wie der Schwartzschen Transformation gesehen werden, die sehr funktionale Aspekte hat (in Lisp ist es als "dekorieren-sortieren-undekorieren" bekannt). OOP existiert ebenso wie prozedurale (C wie Programmierung) und imperative (Bash wie "mach das dann das").

Entwurfsmuster sind wiederkehrende Lösungen für häufig auftretende Probleme. Sie existieren in jeder Sprache. Manchmal werden diese Muster Redewendungen genannt, obwohl dies auch auf Dinge verweisen kann, die viel einfacher sind als ein Muster.

Bei Bedarf können viele der klassischen GOF-Entwurfsmuster in Perl implementiert werden. Perl Design Patterns haben viele gebräuchliche Namen, die mit dem GOF vertraut sind. Es ist nicht notwendig, dass alle von ihnen idiomatische Perl sind.

Beachten Sie beim Erkunden von Designmustern in Perl auch "Design Patterns" von Mark Dominus .

Viele halten die Entwurfsmuster für Sprachmängel . In dieser Perspektive sind Entwurfsmuster wie der Iterator in Perl oft nicht erforderlich. Nicht immer - aber oft.

Schreiben Sie zuerst idiomatisches Perl. Versuchen Sie nicht, C in Perl oder Lisp in Perl oder Java in Perl zu schreiben. Perl ist Perl. Wenn es ein Problem gibt, das größer wird, als es das idiomatische Perl bewältigen kann, und Sie komplexere Klassenstrukturen benötigen, schreiben Sie diese. Kennen Sie die Entwurfsmuster, um erkennen zu können, dass "dieses Problem inzwischen so weit fortgeschritten ist, dass eine abstrakte Fabrik benötigt wird" - aber versuchen Sie nicht, eine abstrakte Fabrik in Perl zu erstellen, wenn Sie keine benötigen.

Einige Bibliotheken existieren sowohl in OOP- als auch in traditionelleren Formen. Siehe Soll ich die funktionsorientierten oder objektorientierten CGI-Schnittstellen verwenden? für eine alte SO-Frage, bei der man fragt, wie man die Bibliothek benutzt.

Perls Haltung zu Paradigmen ist TMTOWTDI (es gibt mehr als einen Weg, dies zu tun). Dies ist einer der Gründe, warum viele Leute Perl scherzhaft als reine Schreibsprache bezeichnen . Es kann viel einfacher sein, es zu schreiben als zu lesen, da der Stil einer anderen Person möglicherweise völlig anders ist als der Ihre.

Trotzdem wird OOP in Perl sicherlich unterstützt. Wenn Sie viel Code von Drittanbietern verwenden, kann es sich um OOP handeln oder nicht, aber für Ihren eigenen Code können Sie OOP nach Herzenslust ausführen. Ich habe OOP zum ersten Mal in Perl gelernt. Ich habe zuerst C ++ ausprobiert und es hat aus irgendeinem Grund nicht "geklickt".

Ich bin in der gleichen Situation, ich benutze Java seit einer langen Zeit,

Der Wechsel zu Perl war ein Schock und eine Erleichterung, aber ich habe ein Buch mit dem Titel "Perl Best Practices" verwendet. Es hilft sehr und wenn Sie die grundlegenden Konzepte von Programmiersprachen verstehen, ist es einfach, einfach damit zu fließen.

Denken Sie daran, mit Perl gibt es mehr als eine Möglichkeit, dies zu tun. Ich habe unzählige Stunden damit verbracht, bestimmten Code zu untersuchen und zu ändern, aber am Ende wird die Arbeit mit einem einfachen Syntaxfehler erledigt.

Es gibt mehrere Möglichkeiten, die Wiederverwendung von Code in Perl zu handhaben. Viele Beispiele machen die Unterscheidung zwischen den Ansätzen nicht klar, und viele Klassen verwenden mindestens zwei.

Ich empfehle, den OO-Stil so oft wie möglich zu verwenden und den EXPORTER nur zu verwenden, wenn Sie mindestens drei oder mehr Klassen haben, die einen relativ kleinen Cluster von Dienstprogrammfunktionen benötigen.

So:

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;

Ich bevorzuge es, den OO-Ansatz und den EXPORTERAnsatz als zwei verschiedene Dimensionen der Codeverfügbarkeit zu visualisieren , als ob die Funktionen von der x- oder y-Achse in das aktuelle Paket kommen würden.

Im obigen Beispiel:

Foo::Barleitet die Methode foo()von der Klasse abFoo

Foo::Bardefiniert eine bar()Methode, damit die polymorphe Methode bar()nicht von der Klasse abgeleitet wirdFoo

Beide Klassen Foound Foo::BarEmpfangsfunktion EXPORTED( nicht Methode ) util()vom Paket ( nicht Klasse )Foo::Util

Die beiden Systeme scheinen kompliziert zu sein, haben aber einen sehr praktischen Nutzen. Das Verfolgen der Mehrfachvererbung kann schnell schwierig werden. Mit der zweiten Dimension der Codeverfügbarkeit können Sie Ihren Vererbungsbaum klein und überschaubar halten.

Wenn eine Funktion monolithisch und relativ dumm ist, verwenden Sie im Allgemeinen EXPORTER, andernfalls die Vererbung. Aber machen Sie sich überhaupt nicht die Mühe, es EXPORTERsei denn, Sie werden wahrscheinlich mehr als 3 oder 4 Pakete umfassen.