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();
    }
}

上面我们看到用户代码必须知道并向Context提供具体的Policy。我们可以像Factory method pattern这样使用Creational Pattern，但是在这种情况下，用户代码仍必须知道具体的Factory类。这要求用户代码实例化并了解有关此类具体实现的存在。

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

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

在简单应用程序中解决此问题的任何提示或要点将很有帮助。

Answer 1

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

客户必须了解不同的策略。该图案有潜在的缺点客户必须先了解策略的差异，然后才能选择合适的一个。客户可能会遇到实施问题。因此，仅当变化行为与客户有关。

如前所述，策略选择机制可以隐藏在其他代码层之后，也可以移动到配置文件中。但基础选择仍必须在某处进行。这只是该模式在选择应用时要注意的缺点。

如何避免用户代码需要了解和实例化策略模式中的具体策略

1 个答案: