도메인 모델의 전략 패턴

Question

도메인 모델의 전략 패턴을 사용해야하는 예제가 있습니다. 나는 시스템의 사용자를 나타내는 사용자 클래스를 가지고있다. 각 사용자는 시스템을 사용하는 동안 요청을 수신 할 수 있습니다. 요청을 수신하면, 일부 처리 로직이 가능하다 :

• 자동
• 수신 요청
• 등에 대한 사용자 알림 요청을 제거 ...

이 경우, 그것을 전략 패턴이 채택 된 것으로 보인다. 이 인터페이스를 구현하는 여러 클래스 (즉, 처리 논리 당 하나의 클래스)가있는 RequestReceivedPolicy이라는 인터페이스가 있습니다. 사용자 클래스는 선택한 정책에 해당하는 클래스의 한 인스턴스에 대한 참조를 보유합니다.

이것은 개체 측에서 올바르게 보입니다. 제 질문은 내 경우에는 관계형 데이터베이스 인 지속성 측면에 관한 것입니다. 사용자는 관리 인터페이스를 통해 정책을 선택합니다. 다음 번에 사용자가 로그인 할 때이 정보를 저장하도록이 선택 항목을 유지하려고합니다. 나는 사용자 클래스에 의해 인스턴스 보류를 지속하는 것에 대해 생각했지만,이 인스턴스는 데이터보다 로직에 관한 것이기 때문에 올바른 방법이라고 생각하지 않습니다.

감사

---

편집 :

public RequestReceivedPolicy { 
    public boolean processRequest(); 
} 

public IgnoreRequestPolicy implements RequestReceivedPolicy { 
    public boolean processRequest(){ 
     //ignore logic 
    } 
} 

public CustomRequestPolicy { 
    private int someData1; 
    private String someData2; 

    public boolean processRequest(){ 
     //custom logic that uses someData1 and someData2 
    } 
} 

Answer 1

정책 선택 지속성의 위치는 해당 정책이 전달 또는 User 클래스로 구성되는 방식 곳 /에 따라

하고, 당신은 정말로 그것을 포기하지 않았습니다.

예를 들어, User 클래스는 이런 일이, 경우

class User 
{ 
    // policy is passed in during ctor 
    public User(object otherArgs, RequestReceivedPolicy policy) 
    { 
    } 
} 

을 ... 다음 User 가능성이 User 외부에 그 환경을 유지해야 생성을 담당하는 클래스입니다. 사용자 개체의 간단한이 같은 RequestReceivedPolicy 참조 보유하고있는 경우

마찬가지로 :

class User 
{ 
    public User(object otherArgs) 
    { 
    } 

    public void setPolicy(RequestReceivedPolicy policy) 
    { 
     _currPolicy = policy;  
    } 

    public RequestReceivedPolicy getPolicy() 
    { 
     return _currPolicy;  
    } 

} 

을 ... 그리고 User 클래스 후 자신의 정책 개체를 설정하는 방법이 없습니다, 다시, 당신은해야 정책 선택을 유지하기 위해 외부 엔티티에 의존합니다. 대신 정책 선택은 다음과 같이 사용자 클래스로 "당겨"경우

:

class User 
{ 
    public User(object otherArgs, RequestReceivedPolicyProvider policyProvider) 
    { 
    } 

    public void someStimulii(object criteria, ...) 
    { 
     _currPolicy = _policyProvider.getPolicy(criteria); 
    } 

} 

... 또는이 ...

class User 
{ 
    public User(object otherArgs) 
    { 
    } 

    public void someStimulii(object criteria, ...) 
    { 
     _currPolicy = PolicyProvider.getInstance().getPolicy(criteria); 
    } 

} 

...나중에 다시 생성/구축 될 때 해당 정책 객체를 가져올 수 있도록 User 객체는 선택 항목을 유지해야합니다. 이 경우, 지속해야 할 것 "기준"이며, RequestReceivedPolicy 그 기준을 반환하는 추가 방법이 있다면 도움이 될 수있는 다음 RequestReceivedPolicyConfig 목적은 사용자 불투명해야

RequestReceivedPolicyConfig policyConfig = _currPolicy.getConfiguration(); 

을 객체이지만 내부적으로는 지속성을 지원하는 간단한 사전이어야합니다. 그런 다음 사용자는 많은 것을 모른 채로 지속 레이어에 전달할 수 있습니다. 지속성 계층에서 가져올 때 공급자를 사용하여 RequestReceivedPolicy을 다시 설치하는 데 사용됩니다. 최소한 RequestReceivedPolicyConfig 객체에는 RequestReceivedPolicy의 클래스 ID가 포함됩니다.

정책이 set/get을 통해 푸시되지만 사용자 개체가 위의 PolicyProvider.getInstance().getPolicy(criteria)과 같은 것을 통해 새 정책을 가져올 수있는 하이브리드를 가질 수 있습니다. 그런 다음 사용자 개체가 RequestReceivedPolicyConfig 기반 접근 방식 또는 외부 지속성 유지.