¿Cuál es una buena manera de refactorizar un módulo monstruo de Perl en submódulos?

Question

Tengo un módulo Perl para un proyecto. Tengo tal vez una docena de programas colgando y muchos de ellos son basura. No había pasado mucho tiempo personal con DBI antes, así que esa parte es reparable, pero lo más importante es que es grande. Literalmente 2KLOCs.

Sería fácil romper esta función (llamémosla Dumb.pm) en módulos separados (Dumb :: FormTools, Dumb :: Database, etc.) excepto que, como dije, hay muchos programas que ya 'usar tonto';

me gustaría exportar funciones exportables de Dumb Dumb :: base de datos a través sin tener que tener variaciones de este una y otra vez:

sub my_dumb_function { return Dumb::Database::my_dumb_function(@_) ; } 

No es que estoy por encima de eso. Es solo que esto parece ser la forma tonta y poco elegante de manejar el problema. Utilicé la excusa "No sé, no, mejor" una vez, y una vez es realmente más de lo que obtienes. ¿Ayuda?

Answer 1

No estoy seguro de cómo lo está usando actualmente (¿actualmente exporta métodos?), Pero puede configurar los nuevos módulos secundarios para permitirle importar sus funciones (usando Exporter), y luego simplemente tener el módulo original explícitamente importar las piezas ahora rotas. Algo así como:

package Dumb; 

use Dumb::Database qw(my_dumb_function); 

1; 

package Dumb::Database; 

use base qw(Exporter); 

our @EXPORT_OK = qw(my_dumb_function); 

sub my_dumb_function { 1; } 

1; 

Answer 2

Es difícil darle consejos específicos debido a diferentes bases de código requieren diferentes estrategias. Refactorizo ​​un módulo con subrutinas de 500 líneas de forma diferente a una con pequeñas subrutinas y una gran cantidad de código repetido. Si también necesito cambiar la interfaz, existen diferentes estrategias para eso.

1. Pon todo en control de fuente. Debe mantener alrededor de las versiones original e intermedia.
2. Si aún no tiene un banco de pruebas, escriba uno. Obtenga la cobertura de prueba tan alta como pueda. Este conjunto de pruebas es la base para preservar el mismo comportamiento en las versiones futuras, errores y todo. Probablemente te encuentres con un programa que depende de un error en el módulo original.
3. Comience a piratear. En cada paso, verifique que el resto todavía pase las pruebas originales y que la interfaz publicada todavía tenga el mismo comportamiento.

Creo que su pregunta real, sin embargo, es "¿Cómo puedo exportar al módulo original que cargó tonto?". Puede proporcionar su propia rutina import que utiliza el método import_to_level del Exportador. Puedes importar a niveles más altos que el inmediato que te cargó. El Dumb::Databaseimport puede cargar sus exportaciones en el espacio de nombres que cargó Dumb aunque es Dumb que carga Dumb::Database.

Answer 3

Supongo que Dumb.pm actualmente usa Exporter. Suponiendo que no desea cambiar el nombre de las funciones (simplemente divídalas en módulos separados), debe poder mantener las definiciones existentes @EXPORT, importar todo de sus submódulos y simplemente reexportar las funciones.

package Dumb; 
use Dumb::FormTools ':all'; 
use Dumb::Database ':all'; 

use Exporter 'import'; 

our @EXPORT = ...; # Unchanged from original version 
our @EXPORT_OK = ...; # Unchanged from original version 

1; 

La etiqueta :all no está definido por defecto. Debe definirlo manualmente (en cada submódulo).

our %EXPORT_TAGS = (all => [ @EXPORT, @EXPORT_OK ]); 
# or, for a module that doesn't export anything by default: 
our %EXPORT_TAGS = (all => \@EXPORT_OK); 

Por otro lado, si un submódulo no tiene @EXPORT_OK funciones, entonces puede saltarse la etiqueta :all y decir use Dumb::Submodule;.

Answer 4

También puede ser que desee ver en Sub::Exporter