这真的是个品味问题。工厂类可以根据需要进行抽象/接口，而工厂方法是轻量级的(而且往往是可测试的，因为它们没有定义的类型，但它们需要一个众所周知的注册点，类似于服务定位器，但用于定位工厂方法)。

这真的是个品味问题。工厂类可以根据需要进行抽象/接口，而工厂方法是轻量级的(而且往往是可测试的，因为它们没有定义的类型，但它们需要一个众所周知的注册点，类似于服务定位器，但用于定位工厂方法)。

我认为这取决于你想要给你的代码带来的松耦合程度。

工厂方法解耦得很好，但是工厂类不行。

换句话说，使用工厂方法比使用简单的工厂(称为工厂类)更容易更改内容。

看看这个例子:https://connected2know.com/programming/java-factory-pattern/。现在，想象一下你想要带来一个新的动物。在Factory类中，您需要更改Factory，但在Factory方法中，不需要，您只需要添加一个新的子类。

当您需要几个具有相同参数类型但具有不同行为的“构造函数”时，它们也很有用。

在对象中使用工厂方法是个好主意:

对象的类不知道它必须创建什么确切的子类 Object的类被设计成它创建的对象由子类指定 对象的类将其职责委托给辅助子类，并且不知道确切的类将承担这些职责

在以下情况下使用抽象工厂类是个好主意:

对象不应该依赖于其内部对象是如何创建和设计的 一组链接的对象应该一起使用，您需要满足这个约束 对象应该由几个可能的链接对象家族中的一个来配置，这些对象将成为父对象的一部分 它需要共享只显示接口而不显示实现的子对象

我喜欢从我的类是“人”的角度来考虑设计模式，而模式是人们彼此交谈的方式。

所以，对我来说，工厂模式就像一个招聘机构。你的公司需要不同数量的工人。这个人可能知道一些他们需要雇佣的人的信息，但仅此而已。

所以，当他们需要一个新员工时，他们会打电话给招聘机构，告诉他们他们需要什么。现在，要真正雇佣一个人，你需要知道很多东西——福利，资格验证，等等。但是招聘的人不需要知道这些——招聘机构会处理所有这些。

以同样的方式，使用Factory允许使用者创建新对象，而不必知道它们是如何创建的，或者它们的依赖关系是什么——他们只需要给出他们实际需要的信息。

public interface IThingFactory
{
    Thing GetThing(string theString);
}

public class ThingFactory : IThingFactory
{
    public Thing GetThing(string theString)
    {
        return new Thing(theString, firstDependency, secondDependency);
    }
}

现在，ThingFactory的消费者可以得到一个Thing，而不需要知道Thing的依赖关系，除了来自消费者的字符串数据。