我正在设计一个系统，让用户可以在按下按钮时指定要执行的特定任务。要执行的任务可以分配给各种事物。所以我有一个名为“ButtonTask”的抽象基类，所有其他任务都从这个基础继承，以实现要执行的任务以及它需要知道的相关数据。这样我可以使用多态来抽象掉所有细节，我只需要调用“PerformTask”而不必关心它实际上是什么类型。到目前为止一切都很好。
实际任务本身可以以不同的方式设置，用户可以通过UI菜单更改任务，可以从文件中读取任务，也可以通过网络消息远程设置任务。
目前我有一个工厂函数，它将根据网络消息创建正确的派生类型，并返回指向基本类型的指针。问题是UI菜单和文件读取感觉他们需要自己的工厂方法来创建对象，因为它们本身就彼此不同。为这类问题设置多个工厂通常是个好主意吗？我真的不能想到解决这个问题的另一种方法，但也许我能做的更好。
答案 0 :(得分：1)
我看到实现多个工厂方法的唯一理由是，如果您希望能够使用不同的初始属性集创建对象，例如允许调用者指定一些属性并为其他属性设置默认值 - 相当于拥有多个公共构造函数。
如果想法是任务独立于它们的启动方式（GUI，网络等），那么我认为不需要单独的工厂方法。相反，我会说工厂的职责之一就是实现这种抽象。换句话说，从代码的三个不同部分调用同一个工厂绝对没问题。但是，将工厂方法设置为静态或使工厂成为单例对象可能是个好主意。
另一方面，如果某些任务只能从网络启动，而其他任务只能从GUI启动，而且只有少数任务可以通过三种方式启动，那么重新考虑设计可能是值得的。一点点。然后，您应该考虑添加另一级抽象Task类，例如CommonTask，GuiTask，NetworkTask，FileTask，并为它们设置工厂而不是ButtonTask。这显然更复杂，是否值得，取决于任务类的数量和代码的结构。
您要避免的情况是工厂用户知道他们可以从工厂接收哪些ButtonTask的特定子类。这是一个“错误的基类”情况，即基类不是整个子类集的真正抽象的情况，并且通过添加如上所述的额外子类层来摆脱它。
除此之外，您可能还想考虑重命名ButtonTask;它听起来就像是一个仅限GUI的任务。