前のエントリで書いたように考えると、Delegateはイベント(何かの処理が行われた)が起源となるはずだ。


ただし、私はまだDelegateの処理を一度も書いたことは無いし、コード上の理解もしてないので全くの間違いかもしれない。


それでも、
・ユーザーがログインした
・ユーザーの投稿数が1上がった
・ユーザーがログアウトした
・管理者が私の投稿を承認した
・管理者がサイトをクローズした
・誰かが、私のuserinfo.phpのページを閲覧した
などなどをひっかけて、自分の好きな処理をこれに絡ませられたら楽しそうだ。


実際はもっと細かくあっても良い。
コアに近い機能ほど、フックさせるためにイベントを細かく分けて「どんな変則的な考え方をされてもフックをさせてあげるべきだ」と考えるだろう。となると、LegacyはほとんどDelegateで書かれてることになりそうだ。




で。Delegateとは何をするためのものかを考えたところで、

「じゃあ、Delegate自身は何？」

ってことになるが、おそらくこれは処理そのものだろう。1つのデリゲートが1つのメソッドに直結している。

じゃあ、処理を行う際に(＝Delegateを発動させる際に)必要なものを考えてみる。

1.　何のイベントに結びつけるか
2.　そのイベントが起こった際に、このDelegateはそのイベントの前で行われるべきか、後で行われるべきか。
3.　このDelegateは処理(＝メソッド／関数)とすると、その関数名(クラス名／インスタンス)
4.　3.に加えて、引数


これらを考えると、Delegate群をマネージするモノが必要になりそうだ。おそらくそれが、DeleagateManagerクラスなのではないだろうか？ただ、このクラスが何をDeleagateに施してくれるかはまだ私は知らない。



逆にDelegateに関して、普通の処理とは違って不要なもの(別の言葉で言うと、「Delegateに期待してはいけないもの」)
A.　返り値・・・そもそも「いつ」「何が」行われるか分からないのに返り値を期待するのは間違っている
B.　環境変数・・・$_SERVERとかの意味ではなく、グローバル変数。Delegateがどのような状況で発動させられるか分からないのに、Delegate内部ではもっとわからない

このA.をフォローするために、引数を参照で渡して引数がその処理を受けた結果となるべきである。
このB.をフォローするために、Delegate内部では極力信頼できるものからの派生変数を使うべきだ。

PHP4における前者の要望を満たすために、XcubeではXCube_Refというクラスを用意している。
Xcubeにおいては、どこでも使えるシングルトンをXCube_Root::getInstance();で取得し使うことにしている。

前者は、PHP5移行では不要となるだろう。しかし、後者はXCubeでは数少ない「XCubeのお仕着せ」になるのではないか。