[Seasar-user:2150] Re: injectDependencyについて

Koichi Kobayashi koichik
2005年 6月 9日 (木) 00:40:49 JST 

小林 (koichik) です．

On Wed, 08 Jun 2005 10:16:53 +0900
Masataka Kurihara <[E-MAIL ADDRESS DELETED]> wrote:

>   感覚だけの話だと、私は逆です。が、もう両方やっといたほうがいいん
> じゃないかなぁ。

いや，S2.2 でやらかした前科持ちとしては (苦笑)，そんな気楽に
「やっといたほうがいい」とは言えません．(^^;
「仕様を変えずに実装を変える」のも言うは易し行うは．．． なので．


>   一方、実装方法はともかく、コンポーネント定義が無いときに、その問題
> 解決をS2ContainerImplでなく、ComponentDeployerFactoryに持って
> いってもらうのが、なぜに「いやーん」なのかちょっと感覚を共有できてない。
> コンテナのカスタマイズポイントを一箇所に集中させたほうが、効率的かと
> 思います。

簡単に言うと「それは Deployer の責務ではない」と考えているから．
# また「責務も義理もない」と言われるかも？ (^^;
まさたかさんの感覚はおそらく，後の二行が示すように Deployer の
責務とか役割とかではなく，「エクステンションポイント」として
見ているのではないかと思います．そこが合意に至らない理由かな？
都合のいいポイントを見つけたので，そこを有効活用したい，という．
で，カスタマイズする方としてはきれいにできるのは分かります．
が，カスタマイズしない状態のコンテナのコードはどうなのか，と．
少なくとも [Seasar-user:2128] の injectDependency() はちょっと
受け入れがたい．
# まさたかさんにとってそこのやり方は重要じゃないのだと思いますが．

実は NullComponentDef はあっていいと思ってます．
しかし，injectDependency() の中だけで，しかもそのメソッドの中で
テンポラリに作るだけというのがとても中途半端に見えちゃうのです．
[Seasar-user:2077] にあったように，getComponentDef() いや，むしろ
getComponentDef0() が NullComponentDef を返すようにして，コンテナ
全体に一貫して導入できればまた違ってくるのですが，現状それは難しい．

なぜに NullComponentDef を一貫して導入できないかというと，
ComponentDef が二つの役割を持っているからです．

1．コンテナが内部の情報を管理するため．
2．アプリがコンテナの情報を参照するため．

NullComponentDef は TooMany〜Def と同様，前者としてのみ
必要なものであり，後者にとっては不要と言っていいものです．
# 個人的には getComponentDef() が TooMany〜Def を返すのも
# ちょっといやーん．

徹底的にやるなら，この二つは明確に分けたいところ．
とはいえ，今から完全に別物にするのはおっかないので，
やるならせいぜい内部用のインタフェースとして

public interface InnerComponentDef extends ComponentDef {
    ComponentDef getView();
}

って感じかな．view は外から見るための ComponentDef．
# Inner っていうとネストしてるっぽいけど他に思いつかなかった．
# Inside？ Local？ とにかく内向きの ComponentDef．
で，実装クラスは全てこいつを implements します．
これで二つの役割を分離する余地ができます．

普通の (？) ComponentDefImpl や SimpleComponentDef とかなら
手っ取り早く

public ComponentDef getView() {
    return this;
}

あるいはちゃんと外向けの ComponentDef 実装を返してもよさげ．
そして！ 標準の NullComponentDef は

public ComponentDef getView() {
    throw new ComponentNotFound〜();
}

個人的には TooMany〜Def も

public ComponentDef getView() {
    throw new TooMany〜();
}

# これで getComponentDef() でも TooMany〜 がスローされます．
# 従来と動きが変わっちゃうけど JavaDoc には TooMany〜 が
# スローされるって書いてあるからこのほうが仕様通りかも (笑)．


そしてS2ContainerImpl の getComponentDef0() は定義が見つからないと
null を返してるけど，それを NullComponentDef を返すようにしちゃう
(なので，InnerComponentDef には現在の null チェック相当のメソッドも
必要，instanceof は私矢田，絶対矢田)．名前も変えた方がいいかも．
当然，各種 ComponentDef 実装クラスのインスタンス化もファクトリで．
そして S2ContainerImpl#injectDependency() は外向けの getComponentDef() を
内向けの getComponentDef0() に変えて injectDependency()，後は実装次第．
っていう感じならいいかな，と．

この場合でも，標準の NullComponentDef はコンポーネントあるいはその
定義に対するアクセスで Deployer を呼ぶのではなく例外をスローするように
実装したい (デプロイしないから) ので，結局まさたかさんの要望とは
結びつかないのですが (苦笑)．

結局の所，少なくとも injectDependency() の振る舞いの変更に関して
Deployer は関係なくて，これはコンテナのポリシーの変更だとしか
思えないわけです．
であるなら，そのカスタマイズとしては Deployer を絡ませるよりコンテナを
いじる方がやっぱり適当だと思う次第．

やっぱりそれはいやだ，static メソッド一発でどうにかしたいという
話だとしても，私の頭の中ではやっぱり Deployer のところじゃなくて
別の形のエクステンションポイントを考える方に行ってしまいそうです．
ん？
もしかして，コンテナに登録されていないコンポーネント (っていうか
ただのオブジェクト) に対する DI を injectDependency() でやるという
カスタマイズが static メソッド一撃 ([Seasar-user:2143] と同等) で
できれば Deployer に拘らなかったりします？
単に使い勝手のいいエクステンションポイントが欲しいだけで Deployer に
拘らないのであれば，もしかしたらアイディアが出ないとも限りませんが．
# 出ないかもしれないけど．


っていうかですね，実はカスタマイズに static メソッドを呼ぶ必要は
なくなるのですけどね．
どうやら S2 コミッタ間で賛成多数になったので，カスタマイズは
dicon 一撃です (笑)．


-- 
<signature>
    <name>Koichi Kobayashi</name>
    <e-mail>[E-MAIL ADDRESS DELETED]</e-mail>
</signature>

Seasar-user メーリングリストの案内