¿Debo cambiar mis utilities.pl a un módulo utilities.pm?

Question

En nuestro producto tenemos un gran archivo de utilidades que requerimos (con hacer) al principio de muchos de nuestros archivos. ¿Hay algún motivo que no sea para convertirlo en un módulo? Por ejemplo, en vez de hacer esto:

do '../dbi_utilities.pl'; 
our ($db,$user,$pw,$attr); 
my $Data = DBI->connect($db,$user,$pw,$attr) or die "Could not connect to database: $DBI::errstr"; 

¿No podría hacer esto ?:

use AppUtil; 
my $Data = AppUtil->connect(); 

¿Cuáles son los pros y los contras de cada estilo?

Answer 1

La única razón para no hacer esto es el tiempo.

Es decir, llevará tiempo limpiar su interfaz, así como todas las aplicaciones de llamadas para usar la nueva interfaz.

Lo que le cueste a tiempo ahora estará más que compensado cuando comience a usar las pruebas adecuadas ("hacer prueba" o "./Build prueba" o simplemente "probar ...") y podrá compruebe que sus cambios no romperán nada antes de registrarlo. Entonces, por supuesto, conviértanse. Solo ten en cuenta que no es una ganancia gratis.

Answer 2

Hacer un módulo de eso lo hará mucho más robusto. En este momento, muchas cosas dependen informalmente unas de otras, pero esas dependencias no son inmediatamente obvias.

Además, le permitiría importar solo parte de las utilidades.

Answer 3

Con do(), carga y compila el archivo utilities.pl cada vez, lo que puede causar problemas si lo hace() más de una vez. Además, use se realiza en compilación lo que permitirá que su programa falle antes, o incluso se pruebe con perl -wc.

Por último, mantenerlo en un paquete le permite proteger su espacio de nombres, que puede ser útil a medida que su proyecto crece.

Aconsejaría convertir su utilites.pl en un paquete Perl adecuado que esté cargado con use.

Answer 4

Obtienes todas las funciones geniales del módulo, el encapsulado, las funciones específicas del módulo, y más.

Sin embargo, tenga en cuenta que al usar use con su sintaxis. crear un objeto para el espacio de nombres de AppUtil y llamar a la subrutina de conexión. para tus utilidades

También debe tener 1; al final de tu archivo.

---

Si seguimos con el otro método significa que no tiene que cambiar ningún código, usted no tiene que añadir al menos 1 al final.

Todos "do", "use" y "require" import, pero el código de alcance que está dentro de ellos (excepto las subrutinas con nombre porque no pueden ocultarse).

Answer 5

Al hacer que su código en un módulo con refactorización adecuada, lo hace fácil de probar. Hablo de esto en mi artículo "Scripts as Modules" para The Perl Journal, así como "How a Script Becomes a Module" en Perlmonks.

Buena suerte,