0

Strategy pattern解耦上下文代码和它使用的策略（或算法或策略）。它有一个优势，Template Pattern因为它可以实现动态行为更改并使用带有委托的组合来实现它。下面是这样的例子。

public class Context{
    private Policy policy;

    public void setPolicy(Policy policy){
        this.policy = policy;
    }

    public performTask(){
        policy.apply(); // delegate policy apply to separate class
        this.contextualWOrk();
    }
}

public interface Policy{
    void apply();
}

public class PolicyX{
     public void apply(){
         //Policy X implementation
     }
}

public class PolicyY{
     public void apply(){
         //Policy Y implementation
     }
}

现在使用上述代码的代码

public class User{
    public void init(Context context){
         context.setPolicy(new PolicyX());
         context.performTask();
    }
}

上面我们看到用户代码必须知道并向上下文提供具体的策略。我们可以像使用创建模式一样Factory method pattern，但在这种情况下，用户代码必须知道具体的工厂类。这需要用户代码实例化并了解此类具体实现的存在。

为了防止这种情况，一个简单的解决方案可以是使用静态方法将输入作为字符串或枚举，并使用“switch-case”或多个“if-else”语句来决定要实例化哪个类并将实现提供给用户代码。但这又违反了“OCP”，因为在添加新类型的情况下将需要修改代码。

如何在简单的应用程序中遵循原则（我不确定 Spring 和其他框架是否可以解决此类问题的某些配置）。

在简单的应用程序中解决此问题的任何提示或关键点都会有所帮助。

4

1 回答 1

1

第 318 页提到了策略模式的这个缺点。

客户必须了解不同的策略。该模式有一个潜在的缺点，即客户必须先了解策略的不同之处，然后才能选择合适的策略。客户可能会遇到实施问题。因此，仅当行为变化与客户相关时才应使用策略模式。

正如您所注意到的，策略选择机制可以隐藏在其他代码层之后，或者移动到配置文件中；但是基础选择仍然必须在某个地方进行。这只是选择应用它时要注意的模式的一个缺点。

于 2019-02-24T18:11:10.080 回答