2011-12-29 5 views
1

が必要とされるどのような私のクラスの構造Strategyパターンの実装

public abstract class BaseUser 
{ 
    protected List<Perm> permissions; 
    public abstract void AddPerm(Perm perm); 
} 

public class NormalUser : BaseUser 
{ 
    public override void AddPerm(Perm perm) 
    { 
     throw new InvalidOperationException("A normal user cant add permissions"); 
    } 
} 

public class SpecialUser : BaseUser 
{ 
    public override void AddPerm(Perm perm) 
    { 
     if(permissions==null) permissions=new List<Perm>(); 
      this.permissions.Add(perm); 
    } 
} 

class Container 
{ 
    List<BaseUser> users; 
} 

です:

  1. コンテナSpecialUserは、追加の権限の機能を持つことになります
  2. ユーザーの両方のタイプを保持します - 完了
  3. 通常のユーザーには許可を許可できません - 完了

    私は

    上で実現するための戦略パターンを選択している私は達成することはできませんよものは、ユーザーの

  4. 両方のタイプである(ユーザーがデフォルトの権限のリストで初期化されます)データベースからの水和されます

この状況でこのパターンを選択するのは間違いありませんか?はいの場合は、どのように要件4に対処しますか?

多くのおかげで、 asolvent

+1

私はここで戦略パターンを見ることができません。共通の基底クラスから2つのクラスを派生させるだけです。あなたの質問はデータアクセスに関するものなので、データベースにアクセスするために使用する技術の種類を指定し、関連するコードを表示する必要があります。 AddPermメソッドについて:私は基本クラスで宣言しませんが、SpecialUserクラスでのみ宣言します。したがって、クライアントがNormalUser型のユーザーに対して呼び出すことができないことは明らかです。 – Jan

+0

こんにちは、返信いただきありがとうございます。私はそれをStrategyと呼んでいます。なぜなら、ユーザーはSpecialまたはNormalのいずれかになるからです。コンテナにはユーザのリスト(Special + Normal)があります。私は間違っているかもしれませんが、私たちは戦略をどのように実装するのでしょうか? (私はそれに精通していませんが、私の解釈が間違っている場合は指導してください) 私は子クラスにメソッドを置くことにした場合、私は親を介して呼び出すことができなくなり、結局私は2つの異なるコレクション。 – asolvent

答えて

1

ご提供された例は、それだけでメソッドのオーバーライドで、本当にstrategy patternのインスタンスではありません。戦略パターンは、コンテキストオブジェクトと戦略オブジェクトとを含む。それにもかかわらず、私はあらゆる可能な場所でOOPを適用しようとする誘惑を避けようとします。継承の代わりに、UserType列挙型と単純なif文を使用して、必要な動作をサポートすることを検討してください。これは、簡単にデータベースにマッピングすることができ、また、コードをシンプルに保つ:

enum UserType { 
Normal, 
Special 
} 

class User { 

public UserType Type { get; set; } 

public override void AddPerm(Perm perm){ 
    switch (this.Type) { 
// logic goes here 
    } 
} 
} 

このタイプの問題は、アプリケーション駆動型のエンタープライズ・データでOOPを使用して、定期的なテーマであると私は通常、できるだけ簡単に物事を維持しよう。必要な機能を提供するために、基本ユーザータイプを派生させる必要がありますか?追加の振る舞いと特性を持っていますか?

+0

元のコードは[Liskov Substitution Principle](http://en.wikipedia.org/wiki/Liskov_substitution_principle)に違反しています。このコードは、[条件付き多型を置き換える](http://martinfowler.com/refactoring/catalog /replaceConditionalWithPolymorphism.html)リファクタリング私は少なくとも私が好きではないか分からない。 – TrueWill

+0

元のコードは、AddPermメソッドのコントラクトが例外のスローを指定していない場合にのみ、LSPに違反します。最終的には、決定は文脈に依存します。パターンと原則はソリューション自体ではなく、ソリューションの基盤を提供できます。ユーザーシステムの典型的な考慮事項を考えると、私はリファクタリングの逆転が適切であると考えています。 – eulerfx

+0

真、それは異なります。リファクタリングの逆戻りは、機能的なスタイルが正当なものである場合にも機能します。しかし私は、この質問に確実に答えるだけの十分な情報はないと思います。 – TrueWill

関連する問題