Le sous Perl, oop ou non?

Question

J'ai un paquet (vraiment juste un sous-programme) J'utilise fréquemment pour analyser le fichier de configuration, etc., il ressemble fondamentalement ceci:

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

Assez basique, mais je me demandais comment (et si) cela pourrait / devrait être réécrite à POO ? Vraiment juste pour apprendre, jamais tout à fait vu quand et pourquoi utiliser bénisse . =)

Merci!

Answer 1

La réponse à la question a plus à voir avec les programmes que vous utilisez le paquet dans le paquet qu'avec lui-même.

Si cela une assez grande apps / scripts basés POO alors il est certainement logique de ce POO parce que c'est ce qu'attend la clientèle (les applications et les gens qui écrivent ces applications / scripts). Ayant également des bibliothèques de style impératif bâton comme un pouce douloureux et créer de la complexité.

A l'inverse, si le paquet est utilisé dans les scripts impératifs plus courts, puis une interface POO va entrer en conflit avec les attentes du client (à savoir les scripts + personnes les développer).

Peut-être que vous migrez entre les approches (par exemple, le script devient grand et peu maniable et ont besoin d'être mieux organisé, peut-être avec POO) dans ce cas, un réglage / config type de classe est un bon endroit pour commencer car ils ont tendance à être bien séparés et ont des lignes claires de responsabilité.

En bref:. Faire ce qui est le plus logique où le paquet est utilisé

Answer 2

Voici (je l'espère!) Un exemple simple d'une abstraction config base OO en utilisant:

• Moose
• MooseX::SimpleConfig

NB. Vous pouvez utiliser d'autres modules ou même rouler votre propre. sert ci-dessous comme un exemple général.

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;

ci-dessus est notre classe de configuration OO. Tout est soigneusement déclaré que vous savez clairement que les options de configuration sont disponibles et valides, par exemple. son auto-documenté.

Donc, pour créer un room à partir d'un fichier de configuration serait:

use RoomConfig;

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

Parce que sa classe i peut aussi instancier un room sans un fichier de configuration:

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

Et avec ces modules particuliers, nous obtenons des fonctionnalités supplémentaires comme ceci:

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

Ainsi ma configuration peut facilement provenir d'un fichier de configuration ou en définissant des attributs.

Et nous pouvons aller plus loin en étendant notre configuration pour différents types de 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;

Et si nous avons utilisé cette config (bathroom.yaml):

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

Ensuite, vous pouvez faire ceci:

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,
);

Notez que marques de $closet_room utilisent à la fois le fichier de configuration et les attributs de réglage.

Notez également que si mon fichier de configuration n'a pas doors (ie. Biens nécessaires), il aurait jeté une erreur sur new_with_config.

Enfin, nous pouvons trouver notre classe introspectant config définie à portée de main:

use RoomConfig;

say "RoomConfig provides the following options:";

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

Maintenant, il n'y a rien qui vous empêche la mise en œuvre plus de cela dans un package de configuration standard, donc à la fin de la journée, ses quelques chevaux pour les cours!

Cependant, la facilité de gestion tout cela est tellement plus facile avec OO et les caractéristiques que ces modules déjà écrits fournissent est grand avantage surtout dans les grands projets.

Answer 3

Vous pouvez jeter un oeil à code source des modules sur CPAN. Par exemple Config :: Général devrait répondre à vos questions ...