5章。DIの概要と、JavaEEでのDI。
DIって昔

JUnitイン・アクション

JUnitイン・アクション

を読んでやっとその意義が判ったクチ*1。それ以前は「コンテナ(=APサーバ)を変えても柔軟に対応できます」みたいな説明が多くて「途中でAPサーバを変える?SunかBEAかIBMが突如倒産しない限りやらないだろ…」とか思ってた。
JavaEE 5のDIでは、注入できるオブジェクトはEJBとかデータソース等、あらかじめ決まっている。Springのごとく何でもOKではない。
ちなみにこの注入というのは、変数宣言の前にアノテーションを書いておくと、実行時にコンテナがデプロイメントディスクリプタファイル読んでその変数に値を入れてくれること。デフォルトコンストラクタ中で注入は行なわれる。
注入先のオブジェクト、注入対象のオブジェクトがスレッドセーフか否かは一部実装依存なので超注意。95ページに注入先のオブジェクトが複数スレッドからの同時アクセスがあるか否かの表があるんで便利。
DI利用でのEJBテスト方法:EJB3.0用のソースはEJBコンテナ以からはアノテーションが無視される(=POJOに見える)事を利用する。
デフォルトコンストラクタはEJBコンテナが利用、引数付きコンストラクタを作って、これをテスト用に利用する(EJBコンテナが注入するメンバーをコンストラクタへの引数で初期化する)

*1:この本は判り易いけど、単体テストを自動化するために元のテスト対象クラスの設計をどんどん変えちゃう というのはちょっとやりすぎな感じが漂う。幾らリファクタリング流行だってなぁ…「メンバ関数の戻り値が修正前と同じだから大丈夫」は能天気過ぎだ。共有資源の排他とかOS固有の振る舞いの差とかUTで検出出来ない問題は多い。