如何避免在策略模式中了解用户代码了解并实例化具体策略

Question

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之类的创建模式，但是在这种情况下，用户代码仍必须知道具体的工厂类。这需要用户代码 intastiate 和知道有关这种具体实现的存在。

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

如何在简单应用中遵循原则（我不确定某些配置是否可以解决此类问题）。

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

Answer 1

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

客户必须意识到不同的策略。模式有潜在的缺点 因为客户必须在策略之前了解如何差异 选择合适的一个。客户可能会面临实施问题。 因此，只有在变化时才能使用策略模式 行为与客户有关。

正如您所指出的那样，策略选择机制可以隐藏在其他代码层后面，也可以移至配置文件。但是，基础选择仍然必须在某个地方进行。这只是选择应用时要注意的模式的缺点。