[Seasar-user:6335] Re: コンテナに登録されているPOJOなクラスにインジェクトしたい

[加藤 潤一]

> 　この辺り、特定のインタフェースを実装することで、具体的にどのような困
> った
> ことになりそうなのでしょうか。後学のために教えて頂けるとうれしいです。
>
> 　というのも、もし自分だったらこのような用途であればジョブスケジューラ
> から
> 呼び出すメソッドを定義したインタフェースを作って、必ずそれを実装するよ
> うに
> 設計すると思ったからです。
>
> 　私の少ない経験からだと、それが問題になるというのは想定できなかったの
> です。
> EJBのように難しいインタフェースの実装は私も嫌ですが、プロジェクト内で作
> った
> インタフェースなら使うことに問題を感じないと言うのが今の私の考えです。
>

そうですね。
その考え方が一般的だと思いますが、なるべくジョブクラス自身は今回作成するフレームワークに依存してほしくないと思っています。

POJOにする理由は、一番はテストのしやすさです。
Strutsを例する話が多いのですが、StrutsのActionクラスはActionクラスを必ず継承しなければなりません。
つまり、自作のActionクラス、StrutsのActionクラス、最終的にはアプリケーションサーバへの依存につながるため、テストがしにくくなります。
(極論すればアプリケーションサーバがないとテストができないってことになります)
しかし、S2Strus,S2JSF,TeedaではアクションクラスをPOJOで実装できますので、これらのフレームワークやアプリケーションサーバがなくてもアクションクラスのテストが可能になります。
テストのしやすさが全然違います。

それに、POJOであれば、そもそも上位のクラスとの関係性がないので、実装コードが比較的シンプルにできると思っています。
私が作るジョブスケジューラはプロジェクト内とかという限定された組織ないで利用する前提でなく、ジョブスケジューラを理解していない人でもすぐに使ってもらえるシンプルな構造にしたいと考えています。
この点もポイントだと思っています。

> 　ちなみに、Seasar2の場合、複数のコンポーネントを配列でDIしてもらうこ
> とが
> 出来たと思うので、自分だったらジョブスケジューラもSeasar2の管理下にお
> いて、
> ジョブを追加する時はdiconファイルの編集だけって感じにすると思います。
>

ジョブクラスをdiconファイルに定義するのは同じ考え方です。

このような回答で回答になっているか疑問ですが、お役に立てれば幸いです。