Chain of Responsibility パターン

デザインパターンちゃんと勉強をしようと思ったので結城さんの本を 1 つ 1 つ実装してみる。 前回の Visitorからの続き。

一つの コマンドオブジェクトと一連の 処理オブジェクトから構成される。各処理オブジェクトは、処理できるコマンドオブジェクトの種類と、自身が処理できないコマンドオブジェクトをチェーン内の次の処理オブジェクトに渡す方法を記述する情報を保持する。また、新たな処理オブジェクトをチェーンの最後に追加する機構を備える。

クラス図

Chain of Responsibility PlantUML

自分としての理解・疑問

  • まさにたらい回し
  • かく其々の機能が解決できるかどうか resolve と次を設定する setNext で繋がって解決策を作っていく
  • 機能とその実行順番を別々に考える事ができるので、そういう構造だとわかれば使えそう。
  • Wikipedia ではログレベルを判断するために使われていてこれもなるほどといったところ。

↓ こういう所が邪悪な感じはするが、これが「設計図」だと考えれば逆にわかりやすいのかも。

<?php
// 邪悪な感じ
$alice->setNext($bob)->setNext($chalie)->setNext($diana)->setNext($elmo)->setNext($fred);

良く良く考えるとオーバーロードができない事で ListVisitor クラスを規定する Visitor クラスの存在意義がなくなってしまっている。というか本当に使っていない。機能的な意味では ListVisitor クラスに集約されているとはいえ ListVisitor 以外を増やす場合にこれではあまり意味がない気はする。

テストが必要なメソッドは protected なものが多かったので、そこは勉強になった。これは別記事書こうと思う。