Stile di programmazione in Perl

Lavoro in Java, quindi sostanzialmente uso il paradigma OOP durante la programmazione. Sto per iniziare a lavorare in Perl e mi chiedevo quale fosse il paradigma seguito dagli sviluppatori di Perl. Nel wiki menziona il fatto che supporta molti paradigmi, ma non sono sicuro di capirlo poiché è un linguaggio di scripting.

Quindi la mia domanda è: i modelli orientati agli oggetti con cui ho familiarità in Java sono idiomatici in Perl o avrò bisogno di cambiamenti significativi nel mio stile di progettazione per scrivere un Perl efficace?

Nota: questa non è una domanda per criticare Perl. In realtà devo lavorare in Perl e vorrei capire come cambierà l'attuale modo di programmare.

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

La natura multi-paradigma del perl può essere vista in cose come la trasformazione di Schwartz che ha aspetti molto funzionali ad esso (in Lisp è noto come "decora-decora-decora"). OOP esiste, così come procedurale (C come la programmazione) e imperativo (bash come "fai questo allora").

I design pattern sono soluzioni ricorrenti a problemi comuni. Esistono in ogni lingua. A volte questi schemi sono chiamati idiomi, sebbene ciò possa riferirsi anche a cose che sono molto più semplici di uno schema.

Se necessario, molti dei classici motivi 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, prendi nota anche di "Pattern di design" di Mark Dominus .

Molti ritengono che i modelli di progettazione siano carenze nella lingua . In quella prospettiva, i modelli di design come 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 quello che il peri idiomatico può gestire e inizi a aver bisogno di strutture di classe più complesse, allora scrivile. 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 creare una fabbrica astratta in Perl se non ne hai bisogno.

Alcune librerie esistono sia in OOP che in forme più tradizionali. Vedi Devo usare le interfacce CGI orientate alle funzioni o agli oggetti? 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ù semplice 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 o meno OOP, ma per il tuo codice puoi fare OOP a tuo piacimento. In realtà ho imparato per la prima volta OOP in Perl. Ho provato prima C ++ e non ha "cliccato" per qualche motivo.

Sono nella stessa situazione, uso Java da molto tempo,

Dopo essermi trasferito in Perl è stato uno shock e un sollievo, ma ho usato un libro intitolato "Best Practices Perl". È di grande aiuto e se capisci i concetti di base dei linguaggi di programmazione è tutto molto semplice.

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

Esistono diversi 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.

Vi consiglio di usare il più possibile lo stile OO e di usare EXPORTER solo quando avete almeno tre o più classi che richiedono un cluster relativamente piccolo di funzioni di utilità.

Così:

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' EXPORTERapproccio come due diverse dimensioni della disponibilità del codice, come se le funzioni arrivassero nel pacchetto corrente dall'asse xo y.

Nell'esempio sopra:

Foo::Barderiva il metodo foo()dalla classeFoo

Foo::Bardefinisce un bar()metodo in modo che il metodo polimorfico bar()non derivi dalla classeFoo

Entrambe le classi Fooe Foo::Barricevono la EXPORTEDfunzione ( non il metodo ) util()dal pacchetto ( non la classe )Foo::Util

I due sistemi sembrano complicati ma hanno un'utilità molto pratica. Tracciare l'ereditarietà multipla può diventare rapidamente complicato. Pertanto, la seconda dimensione della disponibilità del codice consente di mantenere l'albero delle eredità piccolo e gestibile.

Generalmente se una funzione è monolitica e relativamente stupida, usa EXPORTER, altrimenti usa l'ereditarietà. Ma non preoccuparti di usare EXPORTERa meno che ciò che stai per fare non coinvolga probabilmente più di 3 o 4 pacchetti.