3

ドメインモデルの戦略パターンを使用する必要がある例に遭遇しています。システムのユーザーを表すUserクラスがあります。各ユーザーは、システムの使用中にリクエストを受け取る場合があります。リクエストを受信すると、いくつかの処理ロジックが可能になります。

  • リクエストを自動的に削除します
  • 受信したリクエストについてユーザーに通知します
  • 等...

この場合、戦略パターンが適応しているようです。このインターフェイスを実装する複数のクラス（つまり、処理ロジックごとに1つのクラス）を持つRequestReceivedPolicyというインターフェイスがあります。Userクラスは、選択したポリシーに対応するクラスの1つのインスタンスの参照を保持します。

これはオブジェクト側で正しいようです。私の質問は、私の場合はリレーショナルデータベースである永続性の側面に関するものです。ユーザーは、管理インターフェースを介してポリシーを選択します。次回ユーザーがログインしたときにこの情報が保存されるように、この選択を維持したいと思います。Userクラスによって保持されているインスタンスを永続化することを考えましたが、このインスタンスはデータよりもロジックに関するものであるため、正しい方法ではないと思います。

ありがとう

編集：

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
    } 
}
4

1 に答える 1

1

ポリシー選択の永続性の場所は、そのポリシーがクラスに渡されるか、構成される場所/方法によって異なりますUserが、実際にはそれを詳しく説明していません。

たとえば、Userクラスに次のようなものがある場合：

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

...次に、作成を担当するクラスは、User外部でその設定を維持する必要がありUserます。

同様に、Userオブジェクトが単純な場合、次のようにRequestReceivedPolicy参照を保持します。

class User
{
   public User(object otherArgs)
   {
   }

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

   public RequestReceivedPolicy getPolicy()
   {
      return _currPolicy;       
   }

}

...そして、Userクラスには独自のポリシーオブジェクトを設定する方法がないため、ポリシーの選択を永続化するには、外部エンティティに依存する必要があります。

代わりに、ポリシー選択が次のように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 policyConfig =  _currPolicy.getConfiguration();

オブジェクトはRequestReceivedPolicyConfigUserオブジェクトに対して不透明である必要がありますが、内部的には永続性をサポートする単純な辞書である可能性があります。その後、ユーザーはそれについてあまり知らなくても永続層に渡すことができます。永続層からプルする場合RequestReceivedPolicy、プロバイダーを使用して再インストールするために使用されます。少なくとも、各RequestReceivedPolicyConfigオブジェクトにはのクラスIDが含まれます RequestReceivedPolicy。

ポリシーがset/getを介してプッシュされるハイブリッドを作成することは可能ですが、Userオブジェクトは上記のような方法で新しいポリシーをプルすることもできPolicyProvider.getInstance().getPolicy(criteria)ます。その場合でも、Userオブジェクトは、RequestReceivedPolicyConfigベースのアプローチを利用したり、永続性を維持したりできます。外部の。

于 2012-11-02T12:47:31.647 に答える