2010-11-10 3 views
2

Я создаю несколько модулей Perl, которые будут использовать общие утилиты для открытия и закрытия файлов.Где я могу поместить код, общий для двух модулей Perl?

Например,

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); 
    ... 
} 

Теперь, когда Shoul d Я положил openf, чтобы код не дублировался?

+3

Честно говоря, это печальный фрагмент кода, на который нужно смотреть: 'open' - прекрасная функция , используй это. Однако, если вы собираетесь написать что-то вроде этого, по крайней мере, имя, если 'open_for_reading', а также включить имя файла в сообщение об ошибке. Во-вторых, почему у вас есть переменные, которые будут использоваться в качестве дескрипторов файлов в области пакета. Это приведет к целую кучу искажений с вашей стороны, чтобы держать вещи прямо. Подумайте больше о своем дизайне, пока у вас еще есть время. –

+0

о первом) Вы должны понимать, что коды, которые я размещаю здесь, являются всего лишь образцовыми кодами. Очевидно, 'openf' делает намного больше материала в фактическом коде. Здесь я абстрагирую код, который необходим для вопроса, а не публикую целых 100 строк за сомнение в одной строке. о вторых) переменные используются в качестве дескрипторов файлов в области пакета, потому что они используются некоторыми подпрограммами в perl-модуле для открытия/закрытия файлов, например. – Lazer

ответ

9

Я бы сказал, прошу простейшее решение.

Сделайте 3-й модуль, Common.pm или Helpers.pm или MyUtils.pm - сохраните все общие подпрограммы с помощью шаблона.

Затем вы импортируете его из обоих модулей выше, а также в другое место.

Немного другой подход - вместо просто use -ing Commmon.pm - на самом деле унаследовать все ваши модули из него. Таким образом, они могут распространять общие утилиты по мере необходимости в стиле OO.

Мы на самом деле сделали это с большим проектом, подклассифицируя почти 100% модулей из BaseClass.pm или BaseClassPlus.pm, который был его подклассом. Работала очень хорошо и была очень проводящей к хорошо поддерживаемому коду из-за значительно меньшего количества шаблонов. (У меня есть чувство, что мы могли бы проделать большую часть работы с Moose, но это было до того, как я даже знал, что Moose существует)

+0

@ DVK: Где я должен хранить '$ in' и' $ out' тогда? – Lazer

+0

@Lazer - это зависит от того, используется ли '$ in' в любом месте вне подсистемы утилиты. Если нет, сохраните его - как 'my' - в Common.pm – DVK

+0

@Lazer - если он используется вне этих подпрограмм, сохраните его как' our' package variable в Common.pm и экспортируйте его, или - еще лучше - сделайте это ' my' снова и предоставить get/set accessors. Вы будете благодарны за то, что у вас есть 'in()' accessor sub через 1 год, когда вы хотите сделать какую-то чертовски умную вещь, связанную со всеми использованиями '$ in' :) – DVK

Смежные вопросы