2

構成ファイルなどを解析するために頻繁に使用するパッケージ（実際には1つのサブルーチンのみ）があります。基本的には次のようになります。

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

かなり基本的ですが、これをOOPに書き直す方法 (および場合) を考えていましたか? 本当に学ぶためだけに、いつ、なぜblessを使用するかはあまり見たことがありません。=)

ありがとう！

4

3 に答える 3

2

これは（うまくいけば！）以下を使用したOOベースの構成抽象化の簡単な例です。

NB。他のモジュールを使用することも、独自のモジュールをロールすることもできます。以下は一般的な例です。

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


Now there is nothing stopping you implementing most of this in a standard config package so at the end of the day its just horses for courses!

However the ease of managing all this is so much easier with OO and the features that these already written modules provide is big advantage especially in bigger projects.

于 2010-08-25T13:15:39.363 に答える
1

質問に対する答えは、パッケージ自体よりも、パッケージを使用しているプログラムに関係しています。

これが非常に大規模な OOP ベースのアプリ/スクリプトである場合、OOP を使用することは間違いなく理にかなっています。これは、顧客 (アプリと、これらのアプリ/スクリプトを作成する人々) が期待することだからです。また、命令型のスタイル ライブラリが目立ち、複雑さを生み出します。

逆に、パッケージが短い命令型スクリプトで使用されている場合、OOP インターフェイスは顧客の期待 (つまり、スクリプト + それらを開発する人々) と競合します。

おそらく、アプローチ間で移行している可能性があります (たとえば、スクリプトが大きくて扱いにくくなり、おそらく OOP を使用して、より適切に整理する必要がある場合など)、設定/構成の種類のクラスは、適切に分離されている傾向があるため、開始するのに適した場所です。責任の明確な線。

要するに、パッケージが使用される場所で最も意味のあることを行います。

于 2010-08-25T09:08:46.367 に答える
0

CPAN のモジュールからソース コードを見ることができます。たとえば、Config::Generalはあなたの質問に答えるはずです...

于 2010-08-25T10:05:00.297 に答える