2011-12-29 69 views
1

以下是我的课战略模式实现

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. 容器将保留两个类型的用户
  2. SpecialUser将有加权限的功能 - 完成
  3. 普通用户将不被允许添加权限 - 完成

    我选择的战略格局,以实现上述

    我无法实现的事情是

  4. 用户的两种类型将被从数据库(用户将使用的默认权限列表进行初始化)水合

我在这种情况下选择这种模式的权利?如果是,那我该如何解决要求4?

非常感谢, asolvent

+1

我在这里看不到策略模式。你只需从一个公共基类中派生出两个类。你的问题似乎是关于数据访问的,所以你至少要指定你使用哪种技术访问数据库并显示一些相关的代码。 关于你的AddPerm方法:我不会在基类中声明它,而只是在SpecialUser类中声明它。所以很清楚,客户端不能在NormalUser类型的用户上调用它。 – Jan 2011-12-29 09:12:56

+0

嗨,谢谢你的回复。我称之为策略,因为用户将是特殊的或正常的。该容器具有用户列表(特殊+普通)。我可能是错的,但不是我们如何实施战略? (如果我的解释不正确,请指导,如果我的解释不正确) 如果我决定将该方法放在子类中,那么我将无法通过父类调用它,最终我最终会得到2个不同的集合。 – asolvent 2011-12-29 10:11:53

回答

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替代原则](http://en.wikipedia.org/wiki/Liskov_substitution_principle),并且此代码反转[用多态性替换条件](http://martinfowler.com/refactoring/catalog /replaceConditionalWithPolymorphism.html)重构。我不确定我最不喜欢哪一个。 – TrueWill 2011-12-30 01:22:26

+0

如果AddPerm方法的合约未指定可抛出异常,则原始代码仅违反LSP。最终,决策依赖于上下文 - 模式和原则可以为解决方案提供基础,而不是解决方案本身。考虑到用户系统的典型考虑,我认为重构的逆转似乎是合适的。 – eulerfx 2011-12-30 06:12:33

+0

确实,这取决于。当功能风格有保证时,重构逆转也可以工作。不过,我认为我们没有足够的信息来明确回答这个问题。 – TrueWill 2011-12-30 16:17:15