Seasarが与えてくれた「気づき」

Seasar Java

　私は野次馬根性が旺盛で、殊、ソフトウェア関連については可能であれば、たとえほんのわずかでも触ってみるようにしています。そして、良いものは良い、悪いものは悪いと「自ら」判断しています。そんな私は、JDK 1.0時代にJavaは「悪い」と烙印を押し、嫌悪すらしていました。でも今は「良い」になっています。そうして今、「良い」としているSeasarなわけですが、これとの出会いは、私のOOP人生そのものを変えてくれました。

　汎用言語であるJavaには、同じソフトを作るにしても様々な作り方があります。あたりまえのことですが。そして DI は、依存性を廃する（または極力減少させる）ということに着目した作り方の考え方のひとつです。私は、この考え方に感銘しました。というのも、私は前々から、「再利用性」の高さがうたわれていた OOP にそれほど再利用性の高さを感じていなかったからです。そして、薄らぼんやりと「依存性」というのがそれを邪魔をしているという感覚がありました。そして、DI コンテナを使うのが当たり前のようになっていったのですが、最近、ひとつの転機がありました。

Seasa？ 何それ？ そんなもの使えるか

いや、実際こう言われたわけではないのですが、サードパーティ製のライブラリを業務で使うには何かと超えなければいけないハードルがあるのはあたりまえで、超え切れないこともあるということです。では、こんなときどう作ればいいのでしょうか？

　とても簡単でした。たとえば、Hogeインタフェースを実装したHogeImplクラスがあった場合。

public class DI {
    private static HogeImpl singletonHoge = null;

    /**
     * シングルトンが欲しい場合はこっち
     */
    public static Hoge getSingletonHoge() {
        if (singletonHoge == null) {
            singletonHoge = new HogeImpl();

            //初期化処理はここで。
        }
        return singletonHoge;
    }

    /**
     * プロトタイプが欲しい場合はこっち
     */
    public static Hoge getPrototypeHoge() {
        HogeImpl hoge = new HogeImpl();

        //初期化処理はここで。

        return hoge
    }
}

Hogeの実装クラスのインスタンスはこのDIクラスからのみ取得すればいいのです。そうすれば、仕様変更があった場合でも、このDIクラスでたいていのことが吸収できます。