1

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

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 从包含额外逻辑的通用集合继承：

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 属性在请求时返回列表。

哪个是首选，为什么？

4

1 回答 1

2

这仍然是策略模式。

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

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

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

于 2013-10-24T12:08:30.320 回答