2012-01-18 2 views
1

조금 까다로워지고 있습니다. 상태를 관리하기 위해 응용 프로그램에서 상태 패턴을 사용하고 있습니다. 내 응용 프로그램에서 각 상태의 단일 인스턴스를 갖고 싶지만 각 상태 클래스를 단일 클래스로 만들고 싶지 않습니다. 내 마음에 떠오르는 다른 접근법은 StateLocator 클래스를 작성하는 것입니다. StateLocator는 싱글 톤일 수 있으며 모든 상태의 인스턴스를 보유 할 수 있습니다. StateLocator가 좋은 솔루션으로 보이는지 아니면 다른 솔루션이 있는지에 대한 정보를 알려주십시오.이 솔루션은 여전히 ​​상태 인스턴스를 하나만 가질 수 있으며 잠재적으로 싱글 톤을 피할 수 있습니다.상태 디자인 패턴이지만 싱글 톤을 피하십시오.

도움을 주시면 감사하겠습니다. 예 :

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); 또는 무언가 –

관련 문제