Estilo de programación en Perl

Trabajo en Java, así que básicamente uso el paradigma OOP durante la codificación. Estoy a punto de comenzar a trabajar en Perl y me preguntaba cuál es el paradigma que siguen los desarrolladores de Perl. En wiki menciona que es compatible con muchos paradigmas, pero no estoy seguro de entender esto, ya que es un lenguaje de script.

Entonces mi pregunta es: ¿los patrones orientados a objetos con los que estoy familiarizado en Java son idiomáticos en Perl, o necesitaré un cambio significativo en mi estilo de diseño para escribir un Perl efectivo?

Nota: Esta no es una pregunta para criticar a Perl. De hecho, tengo que trabajar en Perl y me gustaría entender cómo cambiará la forma actual en que programo.

La filosofía de Perl tiende a ser la de "hacer lo que es práctico ahora". Si necesita usar OOP, está ahí. No es necesario en todas las soluciones y obligar a una persona a escribir código OOP cuando es un simple problema de tipo "haz esto y luego esto" a menudo es contraproducente.

La naturaleza multi-paradigmática de perl se puede ver en cosas como la transformación de Schwartz que tiene aspectos muy funcionales (en Lisp se le conoce como "decorar-ordenar-decorar"). OOP existe, al igual que el procedimiento (C como programación) y el imperativo (bash como "haz esto y luego esto").

Los patrones de diseño son soluciones recurrentes a problemas comunes. Existen en todos los idiomas. A veces, estos patrones se llaman modismos, aunque esto también puede referirse a cosas que son mucho más simples que un patrón.

Cuando sea necesario, muchos de los patrones de diseño clásicos de GOF se pueden implementar en perl. Los patrones de diseño de Perl tendrán muchos nombres comunes que las personas familiarizadas con el GOF. No es necesario el caso de que todos ellos sean perl idiomáticos.

Al explorar patrones de diseño en perl, tenga en cuenta también los "Patrones de diseño" que no son de Mark Dominus .

Muchos consideran que los patrones de diseño son deficiencias en el lenguaje . En esa perspectiva, los patrones de diseño como el iterador a menudo son innecesarios en perl. No siempre, pero a menudo.

Primero, escribe perl idiomático. No intentes escribir C en perl, o lisp en perl, o java en perl. Perl es perl. Si hay un problema que se hace más grande de lo que Perl puede manejar y comienza a necesitar estructuras de clase más complejas, escríbalas. Conozca los patrones de diseño para poder reconocer que "este problema ha crecido hasta el punto de necesitar una fábrica abstracta", pero no comience a tratar de hacer una fábrica abstracta en perl si no la necesita.

Algunas bibliotecas existen tanto en OOP como en formas más tradicionales. Consulte ¿Debo usar las interfaces CGI orientadas a funciones u objetos? para una vieja pregunta de SO donde se pregunta de qué manera usar la biblioteca.

La postura de Perl sobre los paradigmas es TMTOWTDI (hay más de una forma de hacerlo). Esta es una de las razones por las que muchas personas en broma llaman a Perl un lenguaje de solo escritura . Puede ser mucho más fácil escribirlo que leerlo, porque el estilo de otra persona puede ser completamente diferente al suyo.

Dicho esto, OOP ciertamente es compatible con Perl. Si está utilizando una gran cantidad de código de terceros, puede o no ser POO, pero para su propio código puede hacer POO a su gusto. En realidad, primero aprendí OOP en Perl. Intenté C ++ primero y no hizo "clic" por alguna razón.

Estoy en la misma situación, he estado usando Java durante mucho tiempo,

Me mudé a Perl fue un shock y un alivio, pero utilicé un libro llamado 'Perl Best Practices'. Ayuda mucho y si entiendes los conceptos básicos de los lenguajes de programación, todo es fácil de manejar.

Solo recuerde que con perl hay más de una forma de hacerlo, he pasado innumerables horas mirando cierto código y modificándolo, pero al final hace el trabajo con un simple error de sintaxis.

Hay varias formas de manejar la reutilización de código en Perl. Muchos ejemplos no aclaran la distinción entre los enfoques y muchas clases usan al menos dos.

Aconsejo usar el estilo OO tanto como sea posible y solo use el EXPORTADOR cuando tenga al menos tres o más clases que necesiten un grupo relativamente pequeño de funciones de utilidad.

Entonces:

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;

Prefiero visualizar el enfoque OO y el EXPORTERenfoque como dos dimensiones diferentes de disponibilidad de código, como si las funciones entraran en el paquete actual desde el eje xo y.

En el ejemplo anterior:

Foo::Barderiva el método foo()de la claseFoo

Foo::Bardefine un bar()método para que el método polimórfico bar()no se derive de la claseFoo

Ambas clases Fooy la función de Foo::Barrecepción EXPORTED( no método ) util()del paquete ( no clase )Foo::Util

Los dos sistemas parecen complicados pero tienen una utilidad muy práctica. El seguimiento de la herencia múltiple puede ser complicado rápidamente. Por lo tanto, tener la segunda dimensión de disponibilidad de código le permite mantener su árbol de herencia pequeño y manejable.

En general, si una función es monolítica y relativamente tonta, use EXPORTER, de lo contrario use herencia. Pero no se moleste en usarlo EXPORTERa menos que lo que vaya a hacer sea probable que implique más de 3 o 4 paquetes.