2013/9/28に行われた Hachioji.pm#32 http://atnd.org/events/43853 でLTしたスライドです。Hachioji.pmなのにネタ成分が少なくて慌てて最後のスライドを入れました。というか今回のテーマを守って真面目にトークしたの、今回は自分だけ？

1. 委譲がいいんじゃ
ないでしょうか
尾形 鉄次 (OGATA Tetsuji)
Twitter: @xtetsuji
2013/9/28 Hachioji.pm#32

2. 自己紹介
• 尾形 鉄次 (OGATA Tetsuji)
• Twitter: @xtetsuji
• Blog: http://post.tetsuji.jp/
• 北海道生まれでHokkaido.pmにも良く行く

3. テーマ：
delegate / よしなに

4. 今回は手短に
いつも長々と話してしまって反省しているので

5. 自分自身の継承を想定した
クラス以外は継承しない
• 結構当然なことですが、これを守らず
安易に継承に頼るモジュールが多い
• 今回はPerlの話

6. 題材
• 絶滅危惧種 CGI.pm で (Perl5.20でbye!?)
• こういうコード、内外でよく見ますし
私も昔書いたことあります…反省
• 同じようなものでも、Plack::Requestや
Apache2::RequestRecは、自分自身が継承
されることを意図・言及しているはず

7. 継承による例
package My::CGI;
use strict;
use warnings;
use parent 'CGI';
sub new {
my $class = shift;
...;
my $self = $class->SUPER::new(@_);
return $self;
}
sub foobar {
my $self = shift;
$self->{foobar} = $self->param('foobar'); # これはダメ
...;
}

8. 委譲による例
package My::CGI;
use strict;
use warnings;
sub new {
my $class = shift;
my $self = bless {}, $class;
$self->{cgi} ||= CGI->new; # delegate
return $self;
}
sub foobar {
my $self = shift;
$self->{foobar} = $self->cgi->param('foobar'); # 良い
...;
}

9. 継承がマズイ理由
• 親クラスの設計変更に引きずられる
• 例の様に「ハッシュリファレンスに
blessされたもの」と仮定するとかダメ
• 将来的に内部キーが衝突したり、bless
されるデータ構造が変わるかも

10. 委譲を助けるもの
• 全てのメソッドをそのまま持ってこれ
るのは継承の便利なところ
• 委譲でやるなら AUTOLOAD とかか
• ただパフォーマンス的に問題もある
• 実直にメソッド作るのがよさそう

11. 設計は難しいですね
• 雑なまとめ、LTっぽい
• 継承の使い過ぎは色々厳しい
• 多重継承をプラグイン構造の核として
いるモジュール、結構心折れる

12. うわ、ネタ無い…
• 普段はApacheをmod_perlでSMTPサーバ
にしたりmemcachedサーバにしたりして
います！よろしく！
• 疎結合最高だー！私が普段作るものは
小さい設計のものが多い

13. ご清聴
ありがとうございました