Estilo de programação em Perl

Eu trabalho em Java, então basicamente uso o paradigma OOP durante a codificação. Estou prestes a começar a trabalhar no Perl e fiquei pensando qual é o paradigma que os desenvolvedores do Perl seguem. No wiki, ele menciona que suporta muitos paradigmas, mas não sei se entendi isso, pois é uma linguagem de script.

Portanto, minha pergunta é: Os padrões orientados a objetos com os quais estou familiarizado em Java são idiomáticos no Perl, ou precisarei de alterações significativas no meu estilo de design para escrever Perl eficaz?

Nota: Esta não é uma pergunta para criticar o Perl. Na verdade, tenho que trabalhar em Perl e gostaria de entender como a maneira atual de programar mudará.

A filosofia de Perl tende a ser a de "faça o que é prático agora". Se você precisar usar o OOP, está lá. Não é necessário em todas as soluções e forçar uma pessoa a escrever código OOP quando é um problema simples do tipo "faça isso, então isso, então" é frequentemente contraproducente.

A natureza multiparadigmática do perl pode ser vista em coisas como a transformação schwartziana que possui aspectos muito funcionais (em Lisp é conhecido como "decorar-classificar-undecorate"). OOP existe, assim como procedural (C como programação) e imperativa (festança como "faça isso e depois").

Os Padrões de Design são soluções recorrentes para problemas comuns. Eles existem em todas as línguas. Às vezes, esses padrões são chamados de expressões idiomáticas, embora isso também possa se referir a coisas que são muito mais simples que um padrão.

Quando necessário, muitos dos padrões clássicos de design do GOF podem ser implementados em perl. Os Padrões de Design Perl terão muitos nomes comuns que as pessoas familiarizadas com o GOF. Não é necessário que todos sejam perl idiomáticos.

Ao explorar padrões de design em perl, observe também que "Design Patterns" não é de Mark Dominus .

Muitos consideram que os padrões de design são deficiências no idioma . Nessa perspectiva, os Padrões de Design, como o Iterator, geralmente são desnecessários em perl. Nem sempre - mas frequentemente.

Primeiro, escreva perl idiomático. Não tente escrever C em perl, ou lisp em perl, ou java em perl. Perl é perl. Se houver um problema maior do que o perl idiomático pode lidar e você começar a precisar de estruturas de classes mais complexas, escreva-as. Conheça os padrões de design para poder reconhecer "esse problema agora chegou ao ponto de precisar de uma fábrica abstrata" - mas não comece tentando fazer uma fábrica abstrata em perl, se você não precisar de uma.

Algumas bibliotecas existem em formas OOP e mais tradicionais. Consulte Devo usar as interfaces CGI orientadas a função ou orientadas a objeto? para uma pergunta SO antiga, em que se pergunta para que lado usar a biblioteca.

A posição de Perl sobre paradigmas é TMTOWTDI (há mais de uma maneira de fazê-lo). Essa é uma das razões pelas quais muitas pessoas chamam de brincadeira o Perl de um idioma somente de gravação . Pode ser muito mais fácil escrever do que lê-lo, porque o estilo de outra pessoa pode ser completamente diferente do seu.

Dito isto, o OOP certamente é suportado no Perl. Se você estiver usando muitos códigos de terceiros, pode ou não ser OOP, mas para seu próprio código, você pode fazer OOP com o conteúdo do seu coração. Na verdade, eu aprendi OOP em Perl. Eu tentei C ++ primeiro e ele não "clicou" por algum motivo.

Estou na mesma situação, uso Java há muito tempo,

A mudança para Perl foi um choque e um alívio, mas usei um livro chamado 'Perl Best Practices'. Isso ajuda muito e, se você entender os conceitos básicos das linguagens de programação, é fácil simplesmente fluir com ele.

Lembre-se de que, com o perl, há mais de uma maneira de fazer isso. Passei inúmeras horas olhando para determinado código e modificando-o, mas no final, ele faz o trabalho com um simples erro de sintaxe.

Existem várias maneiras de lidar com a reutilização de código no Perl. Muitos exemplos não deixam clara a distinção entre as abordagens e muitas classes usam pelo menos duas.

Aconselho usar o estilo OO o máximo possível e use o EXPORTADOR apenas quando você tiver pelo menos três ou mais classes que precisem de um cluster relativamente pequeno de funções utilitárias.

Então:

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;

Prefiro visualizar a abordagem OO e a EXPORTERabordagem como duas dimensões diferentes da disponibilidade do código, como se as funções estivessem entrando no pacote atual a partir do eixo x ou y.

No exemplo acima:

Foo::Barderiva o método foo()da classeFoo

Foo::Bardefine um bar()método para que o método polimórfico bar()não seja derivado da classeFoo

Ambas as classes Fooe função de Foo::Barrecebimento EXPORTED( não método ) util()do pacote ( não classe )Foo::Util

Os dois sistemas parecem complicados, mas têm uma utilidade muito prática. O rastreamento de várias heranças pode ficar complicado rapidamente. Portanto, ter a segunda dimensão da disponibilidade do código permite manter sua árvore de herança pequena e gerenciável.

Geralmente, se uma função é monolítica e relativamente burra, use EXPORTER, caso contrário, use herança. Mas não se preocupe em usá-lo, EXPORTERa menos que o que você faça provavelmente envolva mais de 3 ou 4 pacotes.