前回はCommandパターンを使って、各機能を独立した部品にすることに成功しました。
しかし、ボット本体（メインループ）の側にはまだ少し問題が残っています。
- すべてのコマンドに対して順番に
match を試みるのは効率が悪い？ - 「管理者のみ」という権限チェックを全部のコマンドに書くのは面倒では？
- あるコマンドが他のコマンドを知る必要が出てきたら？（例：ヘルプコマンド）
ここで登場するのが Mediator（仲介者）パターン です。司令塔となるオブジェクトを一つ置き、すべての交通整理を任せてしまいましょう。
Mediatorは、複数のオブジェクト（Colleague）間のやり取りを仲介し、カプセル化するパターンです。
今回のケースでは、「ユーザーからのメッセージ入力」と「具体的なコマンド実行」の間を取り持つ司令塔として機能します。
新しいクラス Bot::CommandMediator を作ります。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
| package Bot::CommandMediator;
use Moo;
use Types::Standard qw(ArrayRef Object);
# 登録されたコマンドのリスト
has commands => (
is => 'ro',
isa => ArrayRef[Object],
default => sub { [] },
);
sub register_command {
my ($self, $command) = @_;
push @{$self->commands}, $command;
}
sub dispatch {
my ($self, $text, $user_role) = @_;
# 全コマンドを走査
for my $cmd (@{$self->commands}) {
# マッチするか確認
if (my $args = $cmd->match($text)) {
# 【重要】権限チェックを一元化
if ($cmd->can('required_role') && $cmd->required_role ne $user_role) {
return "⛔ 権限が不足しています（必要権限: " . $cmd->required_role . "）";
}
# 実行
return $cmd->execute($args);
}
}
return "不明なコマンドです。`/help` で一覧を確認してください。";
}
sub help_text {
my ($self) = @_;
my $text = "使用可能なコマンド一覧:\n";
for my $cmd (@{$self->commands}) {
$text .= "- " . $cmd->description . "\n";
}
return $text;
}
1;
|
メインロジックの簡素化
ボット本体のコードは驚くほどシンプルになります。Mediatorに丸投げするだけだからです。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
| use Bot::CommandMediator;
use Bot::Command::Deploy;
use Bot::Command::Log;
use Bot::Command::Help; # 自分自身（Mediator）を使うコマンドも作れる！
my $mediator = Bot::CommandMediator->new;
$mediator->register_command(Bot::Command::Deploy->new);
$mediator->register_command(Bot::Command::Log->new);
# ヘルプコマンドにはMediator自体を渡す
$mediator->register_command(Bot::Command::Help->new(mediator => $mediator));
sub handle_message {
my ($text, $user_role) = @_;
# たった一行！
return $mediator->dispatch($text, $user_role);
}
|
権限管理の一元化
Mediatorパターンの強力な利点の一つが、「横断的な関心事（Cross-cutting concerns）」の集約です。
先ほどの dispatch メソッド内に権限チェックを追加しました。これにより、各Commandクラスは自分の required_role を定義するだけで、チェックロジックそのものを書く必要がなくなりました。
1
2
3
4
5
6
7
8
| package Bot::Command::Deploy;
use Moo;
with 'Bot::Command::Role';
# 権限定義を追加
sub required_role { 'admin' }
# ... execute内には権限チェックコード不要！
|
これで、ボットの脳みそ（Mediator）と手足（Command）がきれいに分かれました。
しかし、まだ足りないものがあります。コマンドが実行された後、その「結果」をどう扱うかです。今は単に文字列を返しているだけですが、実際にはSlackに通知したり、ログに書いたり、Datadogにメトリクスを送ったりしたいはずです。
次回は、Observerパターンを使って、実行結果の通知処理をスマートに追加していきます。
今回の完成コード
Mediatorパターン導入後の主要クラスです。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
| # Bot/CommandMediator.pm
package Bot::CommandMediator;
use Moo;
use Types::Standard qw(ArrayRef Object);
has commands => (
is => 'ro',
isa => ArrayRef[Object],
default => sub { [] },
);
sub register_command {
my ($self, $command) = @_;
push @{$self->commands}, $command;
}
sub dispatch {
my ($self, $text, $user_role) = @_;
for my $cmd (@{$self->commands}) {
if (my $args = $cmd->match($text)) {
# 権限チェック一元化
if ($cmd->can('required_role') && $cmd->required_role ne $user_role) {
return "⛔ 権限が不足しています（必要権限: " . $cmd->required_role . "）";
}
return $cmd->execute($args);
}
}
return "不明なコマンドです。";
}
1;
# 新しいCommand定義例 (Bot/Command/Deploy.pm に追加)
# sub required_role { 'admin' }
|
