2012-01-18 9 views
1

これはややこしいです。私は状態を管理するためにアプリケーションで状態パターンを使用しています。アプリケーションで各状態のインスタンスを1つずつ作成したいのですが、各状態クラスをシングルトンクラスにしたくありません。私の頭に浮かぶもう一つのアプローチは、StateLocatorクラスを書くことです。 StateLocatorはシングルトンにすることができ、すべての状態のインスタンスを保持できます。 StateLocatorが良い解決策に見えるかどうか、あるいは私がまだ州のインスタンスを1つしか持たず、潜在的にシングルトンを避けることができる他の解決策があるかどうかを教えてください。状態のデザインパターンがシングルトンを避ける

何か助けていただければ幸いです。例えば

public interface TestState { 

    public void onTest(); 
    public void onApprove() 

} 

class StateA implements TestState { 
    public void onTest() { 
    } 
    public void onApprove() { 
    } 
} 

class StateB implements TestState { 
    public void onTest() { 
    } 
    public void onApprove() { 
    } 
} 

class StateLocator { 

    private StateA mStateA; 
    private StateB mStateB; 

    StateLocator() { 
     mStateA = new StateA(); 
     mStateB = new StateB(); 
    } 

    public TestState getState(int stateType) { 

     if(stateType == 1) { 
      return mStateA; 
     } else { 
     return mStateB; 
     } 
    } 
} 

答えて

2

StateLocatorは、あなたがそれを使用している方法で、「レジストリ」のパターンデザインについて何を知っていない

http://martinfowler.com/eaaCatalog/registry.html

あり、これはシングルトンを避けるための良い方法です。レジストリはシングルトンになる可能性があります(必ずしもそうである必要はありません)。

+0

私がここで見ている唯一の悪い点は、StateLocatorがすべての可能な状態を知っていることです。 StateLocatorが可能な状態のリスト自体を学習できる方法はありますか? – cppdev

+0

州を発見したい場合は、パブリッシュ/サブスクライブシステム(イベントモデルなど)を持っているオブザーバーパターンを使用できます。これは、とにかくすべての州を発見し、活性化する必要がある。リフレクションを使用してそれらを発見し、それらをパブリッシュ/サブスクライブモデルに登録することができます。それはおそらく過剰です。 – Dessus

+1

レジストリは必ずしもすべての状態を必ずしも知る必要はありません。これは、キーによるユニークな状態の集合の抽象概念を持つかもしれない。だから.... locator.RegisterState(stateA、1);または何か –

関連する問題