Stile di programmazione in Perl

La filosofia di Perl tende ad essere quella di "fare ciò che è pratico ora". Se hai bisogno di usare OOP, è lì. Non è necessario in tutte le soluzioni e costringere una persona a scrivere codice OOP quando è un semplice "fai questo poi questo questo" tipo di problema è spesso controproducente.

La natura multi-paradigma di perl può essere vista in cose come la trasformazione di Schwartzian che ha aspetti molto funzionali a (in Lisp è noto come "decora-ordina-non-decorato"). OOP esiste, così come procedurale (C come programmazione) e imperativo (bash come "fai questo poi questo").

I modelli di progettazione stanno ricorrendo a soluzioni a problemi comuni. Esistono nella lingua ogni . A volte questi modelli sono chiamati idiomi, anche se questo può riferirsi anche a cose che sono molto più semplici di un modello.

Se necessario, molti dei classici pattern di progettazione GOF possono essere implementati in perl. Perl Design Patterns avrà molti nomi comuni che le persone hanno familiarità con il GOF. Non è necessario che tutti siano perl idiomatici.

Quando esplori modelli di design in perl, ti preghiamo di prendere nota di "Modelli di design" non di Mark Dominus .

Molti ritengono che le Design Patterns siano carenze nella lingua . In questa prospettiva, i Pattern design come l'Iterator sono spesso inutili in perl. Non sempre, ma spesso.

Per prima cosa, scrivi perl idiomatico. Non provare a scrivere C in perl, o lisp in perl, o java in perl. Perl è perl. Se c'è un problema che diventa più grande di perl idiatico può gestire e si inizia a richiedere strutture di classe più complesse, quindi scriverle. Conoscere i modelli di progettazione per essere in grado di riconoscere "questo problema è cresciuto al punto di aver bisogno di una fabbrica astratta" - ma non iniziare a provare a fare una fabbrica astratta in Perl se non ne hai bisogno.

Alcune librerie esistono sia in OOP sia in forme più tradizionali. Vedi Dovrei usare l'oggetto orientato alla funzione o all'oggetto interfacce CGI orientate? per una vecchia domanda SO in cui si chiede in che modo utilizzare la libreria.

La posizione di Perl sui paradigmi è TMTOWTDI (c'è più di un modo per farlo). Questo è uno dei motivi per cui molte persone chiamano scherzosamente Perl una lingua di sola scrittura . Può essere molto più facile scriverlo che leggerlo, perché lo stile di un'altra persona potrebbe essere completamente diverso dal tuo.

Detto questo, OOP è certamente supportato in Perl. Se stai usando un sacco di codice di terze parti, potrebbe essere OOP, ma per il tuo codice puoi fare OOP a tuo piacimento. In realtà ho appreso per la prima volta OOP in Perl. Ho provato prima il C ++ e non ha fatto "clic" per qualche motivo.

Sono nella stessa situazione, uso Java da molto tempo,

Avere traslocato in Perl è stato uno shock e un sollievo, ma ho usato un libro chiamato "Perl Best Practices". Aiuta molto e se capisci i concetti di base dei linguaggi di programmazione è facile fluire con esso.

Ricorda che con perl c'è più di un modo per farlo, ho passato innumerevoli ore a guardare un determinato codice e a modificarlo, ma alla fine ha fatto il lavoro con un semplice errore di sintassi.

Ci sono molti modi per gestire il riutilizzo del codice in Perl. Molti esempi non chiariscono la distinzione tra gli approcci e molte classi ne usano almeno due.

Ti consiglio di usare lo stile OO il più possibile e di usare ESPORTATORE solo quando hai almeno tre o più classi che hanno bisogno di un cluster relativamente piccolo di funzioni di utilità.

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;

Preferisco visualizzare l'approccio OO e l'approccio EXPORTER come due diverse dimensioni della disponibilità del codice, come se le funzioni arrivassero nel pacchetto corrente dall'asse xo y.

Nell'esempio sopra:

Foo::Bar deriva il metodo foo() dalla classe Foo

Foo::Bar definisce un metodo bar() in modo che il metodo polimorfico bar() non sia derivato dalla classe Foo

Entrambe le classi Foo e Foo::Bar ricevono EXPORTED funzione ( non metodo ) util() dal pacchetto ( non classe ) Foo::Util

I due sistemi sembrano complicati ma hanno un'utilità molto pratica. Tracciare eredità multiple può diventare fastidioso velocemente. Quindi, avendo la seconda dimensione della disponibilità del codice, è possibile mantenere l'albero di ereditarietà piccolo e gestibile.

Generalmente se una funzione è monolitica e relativamente stupida, utilizzare EXPORT, altrimenti utilizzare l'ereditarietà. Ma non preoccuparti di usare EXPORTER a meno che ciò che farai non implichi più di 3 o 4 pacchetti.