C# 工厂模式这样用可以吗？

在我的程序中，一些对象需要其他对象（依赖项），我使用工厂作为我的创作模式

现在，我如何解决一个简单的依赖性问题

这是一个我正在做什么来解决我的问题的例子。我想知道向Create方法发送所需的对象是否不是什么可怕的错误

//AbstractBackground
// - SpecialBackground
// - ImageBackground
// - NormalBackground
class Screen{
    List<AbstractBackground> list;
    Cursor cursor;
    ContentManager content;

    public void load(string[] backgroundTypes){
        //is this okay? --------------->
        AbstractBackground background = BackgroundFactory.Create(backgroundTypes[0], cursor, content);
        list.add(background);
    }
}

class BackgroundFactory{
    static public AbstractBackground Create(string type, Cursor cursor, ContentManager content){

        if( type.Equals("special") ){
            return new SpecialBackground(cursor, content);
        }

        if( type.Equals("image") ){
            return new ImageBackground(content);
        }

        if( type.Equals("normal") ){
            return new NormalBackground();
        }
    }
}

//抽象背景
//-特殊背景
//-图像背景
//-正常背景
类屏幕{
名单；
光标；
ContentManager内容；
公共无效负载（字符串[]背景类型）{
//这样可以吗？----------->
AbstractBackground=BackgroundFactory.Create（backgroundTypes[0]，光标，内容）；
添加（背景）；
}
}
类背景工厂{
静态公共抽象背景创建（字符串类型、光标、ContentManager内容）{
if（类型等于（“特殊”））{
返回新的SpecialBackground（光标、内容）；
}
if（type.Equals（“image”））{
返回新的ImageBackground（内容）；
}
if（类型等于（“正常”））{
返回新的NormalBackground（）；
}
}
}

答案很简单，看起来不错。如果您抽象地考虑这一点，那么就是通过create方法将对象注入构造函数。这项技术没有什么问题，这是我推荐的

---

以后，如果您需要更改实现，您可以根据需要创建其他create方法，而不会破坏任何东西。

代码中没有什么比这更难看的了，只是如果依赖关系树增长，您创建的工厂方法将变得复杂。

---

为了分解具有各种关联依赖项的类型，您可能最好选择基于

IoC

的工厂。通过在容器中注册依赖项，您将自动注入具有所需依赖项的构造函数。

它是功能性的，但是，如果添加更多类型，它可能会变得麻烦。
根据我个人对简单工厂的偏好，实施方式如下：

enum BackgroundFactoryType
{
  Special,
  Image,
  Normal,
}

static class BackgroundFactory{

  static Dictionary<BackgroundFactoryType, Func<Cursor, ContentManager, AbstractBackground>> constructors;

  static BackgroundFactory()
  {
    //initialize the constructor funcs
    constructors = new Dictionary<BackgroundFactoryType, Func<Cursor, ContentManager, AbstractBackground>>();
    constructors.Add(BackgroundFactoryType.Special, (cursor, content) => new SpecialBackground(cursor, content));
    constructors.Add(BackgroundFactoryType.Image, (_, content) => new ImageBackground(content));
    constructors.Add(BackgroundFactoryType.Normal, (_, __) => new NormalBackground());
  }

  static public AbstractBackground Create(BackgroundFactoryType type, Cursor cursor, ContentManager content)
  {
    if (!constructors.ContainsKey(type))
      throw new ArgumentException("the type is bogus");

    return constructors[type](cursor, content);
  }
}

---

这种方法的一个很好的副作用是，只需做一点工作就可以使这个东西由配置驱动，而不是硬编码。

更适合解释为什么它会出错？不是。我想知道，因为我对现实生活中的工厂模式没有太多的经验。我可以问一个例子吗？我遇到过很多例子，但有些似乎太复杂，无法解决简单的问题，或者我不知道它是否解决了我想做的事情。@user658091如果您的体系结构应该保持简单，请留下。如前所述，您的代码目前没有任何问题。由于

BackgroundFactory

只有静态成员，因此不应该将其标记为

static

？是的，应该标记，构造函数字典也是：）

static class BackgroundFactory{

  static public AbstractBackground Create(BackgroundFactoryType type, Cursor cursor, ContentManager content)
  {
    switch (type)
    {
      case BackgroundFactoryType.Special:
        return new SpecialBackground(cursor, content);
      case BackgroundFactoryType.Image:
        return new ImageBackground(content);
      case BackgroundFactoryType.Normal:
        return new NormalBackground();
      default:
        throw new ArgumentException("the type is bogus");
    }
  }
}