2010-11-10 11 views
2

Je crée plusieurs modules Perl qui utiliseront les utilitaires communs pour ouvrir et fermer des fichiers.Où dois-je mettre du code commun à deux modules Perl?

Par exemple,

mod1.pm

my $in, $out; 

sub openf { 
    my $fname = shift; 
    open $in, "<", $fname or die $!; 
} 

sub one { 
    openf($path); 
    ... 
} 

mod2.pm

my $in, $out; 

sub openf { 
    my $fname = shift; 
    open $in, "<", $fname or die $!; 
} 

sub two { 
    openf($path); 
    ... 
} 

Maintenant, où Shoul d Je mets openf pour que le code ne soit pas dupliqué?

+3

Honnêtement, c'est un morceau de code frustrant à regarder: 'open' est une belle fonction , utilise le. Cependant, si vous voulez écrire quelque chose comme ceci, nommez au moins 'open_for_reading' et incluez le nom du fichier dans le message d'erreur. Deuxièmement, pourquoi avez-vous des variables à utiliser comme des handles de fichier dans la portée du paquet. Cela va conduire à tout un tas de contorsions de votre part pour garder les choses droites. Pensez plus à votre conception pendant que vous avez encore le temps. –

+0

à propos de premier) Vous devez réaliser que les codes que je poste ici sont juste des exemples de codes. Évidemment 'openf' fait beaucoup plus de choses dans le code actuel. Ici, je suis en train d'extraire le code qui est nécessaire pour la question plutôt que d'afficher les 100 lignes entières pour un doute sur une seule ligne. à propos de la seconde) les variables sont utilisées comme descripteurs de fichiers dans la portée du paquet parce qu'elles sont utilisées par certains sous-programmes dans le module perl pour ouvrir/fermer des fichiers, par exemple. – Lazer

Répondre

9

Je dirais aller avec la solution la plus simple.

Créez un 3ème module, Common.pm ou Helpers.pm ou MyUtils.pm - stockez toutes les sous-routines d'aide standard. Vous allez ensuite l'importer à partir des deux modules ci-dessus ainsi que n'importe où ailleurs.

Une approche légèrement différente est - au lieu de simplement use -ing Commmon.pm - à réellement hériter tous vos modules de celui-ci. De cette façon, ils peuvent étendre les utilitaires communs au besoin en mode OO.

Nous l'avons fait avec un gros projet, en sous-classant près de 100% de modules de BaseClass.pm ou BaseClassPlus.pm qui était sa sous-classe. Travaillé très bien et était très conducteur de code bien entretenu en raison de beaucoup moins de passe-partout. (J'ai le sentiment que nous aurions pu faire une grande partie du travail avec Moose mais c'était avant même que Moose n'existât)

+0

@DVK: Où devrais-je garder '$ in' et' $ out' alors? – Lazer

+0

@Lazer - cela dépend si '$ in' est utilisé n'importe où en dehors des sous-utilitaires. Sinon, gardez-le - comme 'my' - dans Common.pm – DVK

+0

@Lazer - s'il est utilisé en dehors de ces routines, gardez-le comme variable de notre paquet dans Common.pm et exportez-le, ou - mieux encore - faites-le' my' à nouveau et fournir get/set accesseurs. Vous vous remerciez d'avoir un sous accesseur 'in()' en 1 an quand vous voulez faire quelque chose diaboliquement intelligent impliquant toutes les utilisations de '$ in' :) – DVK