工厂模式建造许多派生类 [英] Factory Pattern to build many derived classes

问题描述

我有一个工厂对象 ChallengeManager 来生成一个挑战对象一场比赛我建立的实例。有许多挑战。每个挑战类派生的构造是不同的，但是它们之间存在一个通用的接口，在基类中定义的。

I have a factory object ChallengeManager to generate instances of a Challenge object for a game I'm building. There are many challenges. The constructors for each Challenge class derivation are different, however there is a common interface among them, defined in the base class.

当我称之为 manager.CreateChallenge（），它返回挑战，这是一个实例派生类型。

When I call manager.CreateChallenge(), it returns an instance of Challenge, which is one of the derived types.

在理想情况下，我想保持代码的派生类本身内部的对象构造，因此所有与该对象的代码是同一地点。例如：

Ideally, I would like to keep the code for the object construction inside the derived class itself, so all the code related to that object is co-located. Example:

class Challenge {}

class ChallengeA : Challenge {
  public static Challenge MakeChallenge() {
    return new ChallengeA();
  }
}

class ChallengeB : Challenge {
  public static Challenge MakeChallenge() {
    return new ChallengeB();
  }
}

现在，我的 ChallengeManager。 CreateChallenge（）通话只需要决定类调用 MakeChallenge（）上。建设的实现是由类本身包含的。

Now, my ChallengeManager.CreateChallenge() call only needs to decide the class to call MakeChallenge() on. The implementation of the construction is contained by the class itself.

使用这种模式，每一个派生类必须定义一个静态 MakeChallenge（）方法。然而，由于该方法是静态的，我不能够利用接口这里，要求它。

Using this paradigm, every derived class must define a static MakeChallenge() method. However, since the method is a static one, I am not able to make use of an Interface here, requiring it.

这不是什么大不了的事，因为我可以很容易地记住正确的方法签名添加到每个派生类。不过，我想知道是否有一个更优雅的设计，我应该考虑的。

It's not a big deal, since I can easily remember to add the correct method signature to each derived class. However, I am wondering if there is a more elegant design I should consider.

推荐答案

我真的很喜欢你所描述的模式，经常使用它。我喜欢做的方式是：

I really like the pattern you are describing and use it often. The way I like to do it is:

abstract class Challenge 
{
  private Challenge() {} 
  private class ChallengeA : Challenge 
  {
    public ChallengeA() { ... }
  }
  private class ChallengeB : Challenge 
  {
    public ChallengeB() { ... }
  }
  public static Challenge MakeA() 
  {
    return new ChallengeA();
  }
  public static Challenge MakeB() 
  {
    return new ChallengeB();
  }
}

这模式有很多很好的特性。没有人能做出一个新的挑战，因为它是抽象的。没有人可以让一个派生类，因为挑战的默认构造函数是私有的。没有人可以在 ChallengeA获得或 ChallengeB ，因为它们是私有的。您定义的接口挑战，那就是客户需要了解的唯一接口。

This pattern has many nice properties. No one can make a new Challenge because it is abstract. No one can make a derived class because Challenge's default ctor is private. No one can get at ChallengeA or ChallengeB because they are private. You define the interface to Challenge and that is the only interface that the client needs to understand.

当客户希望有一个 A ，他们问挑战一，和他们得到它。他们并不需要担心的事实幕后， A 是 ChallengeA 实施。他们只是得到一个挑战，他们可以使用。

When the client wants an A, they ask Challenge for one, and they get it. They don't need to worry about the fact that behind the scenes, A is implemented by ChallengeA. They just get a Challenge that they can use.

这篇关于工厂模式建造许多派生类的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！