Question

目前，我有一个标准的策略模式实现，简化：

public interface IStrategy
{
    IList<Dog> GetDogs();

}

public class DogStrategy: IStrategy
{
    public IList<Dog> GetDogs()
    {
       return new List<Dog>();
    }
}

我还有一个使用策略的类：

public class DogCollection
{
    private IStrategy strategy;
    public IStrategy Strategy
    {
        get { return strategy; }
        set
        {
            if (strategy == null || value.GetType() != strategy.GetType())
            {
                strategy = value;
                //do stuff
            }
        }
  }

问题：我发现在2个位置实现了模式的是接口开始扩散一点。这是可管理和灵活的，但我知道同事会因为文件太多而感到不安 - 他们不喜欢设计模式。此外，我需要使用策略通用的一些逻辑，因此集合需要具有它继承的抽象类。

我在思考而不是使用所有这些接口让DogCollection从包含额外逻辑的Generic Collection继承：

public class DogCollection : GenericCollection<Dog>

我可以使用Loader属性而不是IStrategy属性。然后我可以删除两种策略模式的各种文件：

public abstract class GenericCollection<T> 
{
    private Func<IList<T>> loader;
    public Func<IList<T>> Loader
    {
        get { return loader; }
        set 
        {
            loader = value; 
            //do stuff
        }
    }
}

不是通过在各种条件下实例化具体策略实现来设置策略，而是在DogCollection中设置策略，我只需创建一个包含例程的静态类来获取不同的Dogs并分配Loader属性。然后可以使用loader属性在请求时返回列表。

哪个是首选，为什么？

Answer 1

这仍然是策略模式。

请注意，设计模式通常用于克服您使用的编程语言中的缺陷。

在C＃函数中，通过使用委托类型几乎就是所谓的一等公民，实际上不需要将策略包装到接口和类中。

效果基本相同，我更倾向于使用Func<>委托的第二种方法：更少的代码，更少的接口，更少的类，更少的文件，更少的混淆。

战略模式替代实施

1 个答案: