Che cosa è un buon modo di refactoring un modulo Perl mostro in sottomoduli?

Question

Ho un modulo Perl per un progetto. Ho programmi forse una dozzina appesi fuori di esso e un sacco di esso è spazzatura. Non avevo speso molto stretta tempo personale con DBI prima, in modo che una parte è risolvibile, ma la cosa più importante è che è grande. Letteralmente 2KLOCs.

Sarebbe facile per rompere questa funzione (chiamiamola Dumb.pm) in moduli separati (Dumb :: FormTools, Dumb :: Database, etc.) ad eccezione, come ho detto, c'è un sacco di programmi che gia ' utilizzare Dumb;'

Vorrei esportare le funzioni esportabili di Dumb Dumb :: database tramite senza dover avere variazioni di questo più e più volte:

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

Non è che io sono al di sopra. E 'solo che questo mi sembra il modo muto e poco elegante di gestire il problema. Ho usato il "Non so niente di meglio" scusa una volta, e una volta che è in realtà più di quanto si ottiene. Aiuto?

Answer 1

Non sono sicuro di come si sta utilizzando è (fa attualmente metodi di esportazione?), Ma è possibile impostare i nuovi moduli bambino per consentire di importare le loro funzioni (utilizzando Exporter), e poi basta avere il modulo originale in modo esplicito di importazione i pezzi ormai scoppiata. Qualcosa di simile:

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

E 'difficile dare una consulenza specifica, perché basi di codice diversi richiedono strategie diverse. Ho refactoring un modulo con le subroutine 500 linee in modo diverso di uno con piccole subroutine e un sacco di codice ripetuto. Se ho bisogno di cambiare l'interfaccia di troppo, ci sono strategie diverse per questo.

1. Prendi tutto in controllo del codice sorgente. È necessario mantenere intorno le versioni originali e intermedie.
2. Se non si dispone già di una suite di test, scriverne uno. Prendi il copertura di test il più in alto possibile. Questa suite di test è la linea di base per preservare lo stesso comportamento nelle versioni future, insetti e tutti. Probabilmente stai andando a incontrare un programma che dipende da un bug nel modulo originale.
3. Avvia hacking. Ad ogni passo, verificare che il resto passa ancora il test originali e che l'interfaccia pubblicata risultati ancora lo stesso comportamento.

Penso che la tua domanda attuale, però, è "Come posso esportare al modulo originale che ha caricato Dumb?". È possibile fornire una propria routine import che utilizza il metodo di import_to_level Exporter. È possibile importare a livelli più elevati rispetto a quello immediato che è stato caricato. Il Dumb::Database import può quindi caricare le proprie esportazioni nel namespace che ha caricato Dumb anche se è Dumb che carica Dumb::Database.

Answer 3

Suppongo che Dumb.pm attualmente utilizza Exporter. Partendo dal presupposto che non si desidera rinominare le funzioni (solo dividerli in moduli separati), si dovrebbe essere in grado di mantenere le definizioni esistenti @EXPORT, importare tutto dal tuo sottomoduli, e semplicemente ri-esportare le funzioni.

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;

Il tag :all non è definito per impostazione predefinita. È necessario definire manualmente (in ogni modulo).

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

D'altra parte, se un modulo non ha funzioni @EXPORT_OK, allora si può saltare il tag :all e dire use Dumb::Submodule;.

Answer 4

Si potrebbe anche voler guardare in Sub :: Esportatore