Style de programmation en Perl

Je travaille en Java, donc en gros j'utilise le paradigme OOP lors du codage. Je suis sur le point de commencer à travailler en Perl et je me demandais quel est le paradigme que les développeurs Perl suivent. Dans wiki, il mentionne qu'il prend en charge de nombreux paradigmes, mais je ne suis pas sûr de comprendre cela, car il s'agit d'un langage de script.

Ma question est donc la suivante: les modèles orientés objet que je connais en Java sont-ils idiomatiques en Perl, ou aurai-je besoin de modifications importantes de mon style de conception pour écrire en Perl efficace?

Remarque: Il ne s'agit pas de critiquer Perl. En fait, je dois travailler en Perl et j'aimerais comprendre comment la façon dont je programme va changer.

La philosophie de Perl tend à être celle de «faire ce qui est pratique maintenant». Si vous devez utiliser la POO, c'est là. Il n'est pas nécessaire dans toutes les solutions et forcer une personne à écrire du code POO quand il s'agit d'un simple problème de type "faites ceci puis ceci alors ce" est souvent contre-productif.

La nature multi-paradigme de perl peut être vue dans des choses telles que la transformation schwartzienne qui a des aspects très fonctionnels (en Lisp, elle est connue comme "décorer-trier-décorer"). La POO existe, de même que procédurale (programmation comme C) et impérative (bash comme "faites ceci puis ceci").

Les modèles de conception sont des solutions récurrentes aux problèmes courants. Ils existent dans toutes les langues. Parfois, ces modèles sont appelés idiomes, bien que cela puisse également se référer à des choses beaucoup plus simples qu'un modèle.

Si nécessaire, la plupart des modèles de conception GOF classiques peuvent être implémentés en perl. Perl Design Patterns aura de nombreux noms communs que les gens familiers avec le GOF. Il n'est pas nécessaire que tous soient des perl idiomatiques.

Lorsque vous explorez des modèles de conception en perl, veuillez également prendre note des «modèles de conception» ne sont pas de Mark Dominus .

Beaucoup considèrent que les modèles de conception sont des lacunes dans la langue . Dans cette perspective, les modèles de conception tels que l'itérateur sont souvent inutiles en perl. Pas toujours - mais souvent.

Tout d'abord, écrivez perl idiomatique. N'essayez pas d'écrire C en perl, ni lisp en perl, ni java en perl. Perl est perl. S'il y a un problème qui devient plus important que perl idiomatique ne peut gérer et que vous commencez à avoir besoin de structures de classe plus complexes, écrivez-les. Connaître les modèles de conception pour pouvoir reconnaître "ce problème est devenu au point d'avoir besoin d'une usine abstraite" - mais ne commencez pas à essayer de créer une usine abstraite en perl si vous n'en avez pas besoin.

Certaines bibliothèques existent sous des formes OOP et plus traditionnelles. Voir Dois-je utiliser les interfaces CGI orientées fonction ou orientées objet? pour une vieille question SO où l'on demande de quelle manière utiliser la bibliothèque.

La position de Perl sur les paradigmes est TMTOWTDI (il y a plus d'une façon de le faire). C'est l'une des raisons pour lesquelles beaucoup de gens appellent en plaisantant Perl un langage en écriture seule . Il peut être beaucoup plus facile de l'écrire que de le lire, car le style d'une autre personne peut être complètement différent du vôtre.

Cela étant dit, OOP est certainement pris en charge en Perl. Si vous utilisez beaucoup de code tiers, il peut ou non s'agir de POO, mais pour votre propre code, vous pouvez faire de la POO à votre guise. En fait, j'ai d'abord appris la POO en Perl. J'ai d'abord essayé C ++ et il n'a pas "cliqué" pour une raison quelconque.

Je suis dans la même situation, j'utilise Java depuis très longtemps,

Avoir déménagé à Perl a été un choc et un soulagement, mais j'ai utilisé un livre intitulé `` Perl Best Practices ''. Cela aide beaucoup et si vous comprenez les concepts de base des langages de programmation, tout est facile à suivre.

N'oubliez pas qu'avec Perl, il y a plus d'une façon de le faire, j'ai passé d'innombrables heures à regarder certains codes et à les modifier, mais au final, cela se fait avec une simple erreur de syntaxe.

Il existe plusieurs façons de gérer la réutilisation du code en Perl. De nombreux exemples ne font pas clairement la distinction entre les approches et de nombreuses classes en utilisent au moins deux.

Je conseille d'utiliser autant que possible le style OO et de n'utiliser l'EXPORTATEUR que si vous avez au moins trois classes ou plus qui ont besoin d'un cluster relativement petit de fonctions utilitaires.

Donc:

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;

Je préfère visualiser l'approche OO et l' EXPORTERapproche comme deux dimensions différentes de la disponibilité du code, comme si les fonctions venaient dans le package actuel à partir de l'axe x ou y.

Dans l'exemple ci-dessus:

Foo::Bardérive la méthode foo()de la classeFoo

Foo::Bardéfinit une bar()méthode pour que la méthode polymorphe bar()ne soit pas dérivée de la classeFoo

Les deux classes Fooet Foo::Barreçoivent la EXPORTEDfonction ( pas la méthode ) util()du package ( pas la classe )Foo::Util

Les deux systèmes semblent compliqués mais ont une utilité très pratique. Le suivi de l'héritage multiple peut devenir difficile et rapide. Donc, avoir la deuxième dimension de la disponibilité du code, vous permet de garder votre arbre d'héritage petit et gérable.

Généralement, si une fonction est monolithique et relativement stupide, utilisez EXPORTER, sinon utilisez l'héritage. Mais ne vous embêtez pas EXPORTERdu tout à moins que ce que vous allez faire soit susceptible d'impliquer plus de 3 ou 4 packages.