Perl read_config sub, упс или нет? - PullRequest
Новая
       29

Perl read_config sub, упс или нет?

2 голосов
/ 25 августа 2010

У меня есть пакет (на самом деле только одна подпрограмма), который я часто использую для разбора файла конфигурации и т. Д. В основном это выглядит так: 

sub get_settings {
        my %config;
        my $config = 'path...';

        unless(-r $config) {
                die("Couldn't read config");
        }
        open CONFIG, '<', $config or die $!;
        while(<CONFIG>) {
                next if (($_ eq "\n") or /^\;/);
                chomp;
                my($setting, $value) = split(/=/, $_);
                $config{$setting} = $value;
        }
        return %config;
}

Довольно простой, но мне было интересно, как (и если) этоможно / нужно переписать в ООП ?На самом деле просто для обучения, никогда не видел, когда и зачем использовать благослови .=)

Спасибо!

Ответы [ 3 ]

2 голосов
/ 25 августа 2010

Вот (надеюсь!) Простой пример абстракции конфигурации на основе ОО с использованием:

Примечание.Вы можете использовать другие модули или даже свернуть свои собственные.Ниже приведен только общий пример.

RoomConfig.pm 

package RoomConfig;
use Moose;
with 'MooseX::SimpleConfig';

has doors   => (is => 'rw', isa => 'Int', required => 1);
has windows => (is => 'rw', isa => 'Int', default  => sub {0});

1;

Итак, выше наш класс конфигурации OO.Все аккуратно объявлено, так что вы четко знаете, что параметры конфигурации доступны и действительны, т.е.самодокументируемый.

Таким образом, для создания room из файла конфигурации было бы: 

use RoomConfig;

my $box_room = RoomConfig->new_with_config( configfile => 'box_room.yaml' );

Поскольку это класс, который я также могу создать room без файла конфигурации:

my $cupboard       = RoomConfig->new( doors => 1 );
my $utility_room   = RoomConfig->new( doors => 2 );
my $master_bedroom = RoomConfig->new( 
    doors      => 1,
    windows    => 2,   # dual aspect
);

А также с этими конкретными модулями мы получаем дополнительные функции, такие как: 

# below throws exception because room must have a door!
my $room_with_no_door_or_window = RoomConfig->new;

Таким образом, моя конфигурация может легко прийти из файла конфигурации или путем установки атрибутов.


И мы можем пойти дальше, расширив наш конфиг для различных типов rooms:

BathRoomConfig.pm 

package BathRoomConfig;
use Moose;
extends 'RoomConfig';

has loos  => (is => 'rw', isa => 'Int', default  => sub {0});
has sinks => (is => 'rw', isa => 'Int', default  => sub {0});
has baths => (is => 'rw', isa => 'Int', default  => sub {1});

1;

И если мы использовали этот конфиг (bathroom.yaml): 

doors:  1
windows:    1
bath:   1
loos:   1
sinks:  2

Тогда вы можете сделать это: 

use BathRoomConfig;

my $upstairs_bathroom = BathRoomConfig->new_with_config( 
    configfile => 'bathroom.yaml' 
);

my $closet_room = BathRoomConfig->new_with_config( 
    configfile => 'bathroom.yaml',
    baths      => 0,
    sinks      => 1,
    windows    => 0,
);

Обратите внимание, что $closet_room использует как файл конфигурации, так и атрибуты настроек.

Также обратите вниманиечто если бы мой конфигурационный файл не имел doors (то есть, обязательное свойство), то он вызвал бы ошибку на new_with_config.


И, наконец, мы можем найти удобный анализ нашего определенного класса конфигурации.: 

use RoomConfig;

say "RoomConfig provides the following options:";

for my $attr (RoomConfig->meta->get_attribute_list) {
    next if $attr eq 'configfile';
    say '-> ', $attr;
}


Теперь ничто не мешает вам реализоватьПолучите большую часть этого в стандартном конфигурационном пакете, так что в конце дня это просто лошади для курсов!

Однако легкость управления всем этим намного проще с ОО, а функции, которые предоставляют эти уже написанные модули, являются большим преимуществом, особенно в больших проектах.

1 голос
/ 25 августа 2010

Ответ на вопрос больше связан с программами, в которых вы используете пакет, чем с самим пакетом.

Если это довольно большие приложения / скрипты на основе ООП, то, безусловно, имеет смысл их ООП, потому что именно этого ожидает клиент (приложения и люди, пишущие эти приложения / скрипты). Также наличие императивных библиотек стилей торчит, как больной большой палец, и создает сложность.

И наоборот, если пакет используется в более коротких императивных сценариях, то интерфейс ООП будет конфликтовать с ожиданиями клиента (т. Е. Сценарии + люди, разрабатывающие их).

Возможно, вы переходите с одного подхода на другой (например, сценарий становится большим и громоздким, и его необходимо лучше организовать, может быть, с помощью ООП), и в этом случае класс Class с настройками / конфигурацией - это хорошее место для старта, поскольку они, как правило, хорошо разделены и имеют четкие границы ответственности.

Короче говоря: делайте то, что лучше всего подходит для использования пакета.

0 голосов
/ 25 августа 2010

Вы можете взглянуть на исходный код модулей на CPAN. Например, Config :: General должен ответить на ваши вопросы ...

...