オブジェクト指向研究会！コミュのSingletonとインスタンス変数の併用によるメリット

現状の設計では、Propertiesファイルを読み込みインスタンスをフィールドに保持しpublicなgetメソッドが呼ばれたときにkeyを使って必要な値を戻す「PropUtils」なるクラスが存在する。
これは１つのアプリケーションのプロパティ（設定値）を外部ファイル１つにまとめることで変更時の柔軟性をあげるための手段として取り入れたわけだけど、ぶっちゃけ今回の掲示板だと記述しているのはSQL文とDB関連情報くらいなので変更する可能性はほとんどない。
そもそもアジャイル開発手法とか言いつつ、変更を事前に予測したクラス設計をするのもどうかとおもうわけだけど、研究会による研究と検証ってことでその辺はご勘弁ｗ


で。
メンバーであるD君に、この「PropUtils」をコーディングしてもらった結果シングルトンパターンとインスタンス変数でPropertiesのインスタンスをフィールドに持たせる形での実現がされました。

ここで、ある疑問を顧問の先生から投げかけられる。


「シングルトンクラスは１つのインスタンスしか持たないわけだけど、だったらフィールドのインスタンス変数をstaticにしても同じだよね。どっちがいいんだろね」
と。

そこで、マーチンファウラー著の「エンタープライズアプリケーションアーキテクチャ」の第18章ベースパターン項目のスレッドセーフレジストリの部分を参考に昨夜その場にいたメンバーで議論した結果まがりなりにも「仮答え」的なものがでたのでここで報告を。



・シングルトンとインスタンス変数を合わせることで得られるメリットとは

そもそも、ファイラーのいうレジストリがどんなものを指しているのかこの部分だけだと僕的に出た答えは

P.506下部にある「メソッドをレジストリに配置してレジストリをスタブモードで初期化し、スタブの振る舞いをサブクラスに保持することによって、テストに必要なコードを分離することができる」

これがそのまんま、そうなのかなと。

ソースコードを実際に書いて説明しますと・・・



class Registry{
protected PersonFinder personFinder = new PersonFinder();
private static Registry soleInstance = new Registry();

private static Registry getInstance(){
//静的な自身のインスタンスを返す
return soleInstance;
}

public static void initialize(){
//レジストリの再初期化
soleInstance = new Registry();
}

public static void initializeStub(){
//サブクラスの代入
soleInstance = new RegistryStub();
}

public static PersonFinder personFinder(){
//自身のインスタンスのインスタンス変数を参照
return getInstance().personFinder;
}
}
class RegistryStub extends Registry{
public RegistryStub(){
Soleinstance = new Sub();
}
}
class Sup{
//コードA
}

class Sub extends Sup{
//コードB
}


コードBをテストコードとして利用するもよし、Registryクラスのサブクラスを複数作って用途ごとに分けてManegerで管理するもよし。みたいな。

インスタンス変数の中身が違うRegistryクラスは常に１つで用途ごとにインスタンス変数の中身を変更していくわけだけど、同じ静的な値を使えると。

ファウラーのいう「置換」ってこういうことなんじゃないですかねぇ？