java中的工厂模式

Question

我正在使用据称使用工厂模式的 java 代码，但我并不完全相信该模式。

我的代码是这样做的：

// the factory
class SomeFactoryImpl {
   Set<SomeClass> getSomeListOfObjects();
}

在代码中的某个地方：

{ ...
    SomeFactory factory = new SomeFactoryImpl();
    Set<SomeClass> list = factory.getSomeListOfObjects();
}

我正在思考的一点是，如果工厂类没有静态 create() 方法，那么将需要实例化一个工厂，这IMO 应该和实例化对象本身一样复杂。

我认为这样的工厂可以返回要生成的对象集合的论点还不够好。 我觉得如果在实际从工厂创建对象之前需要创建工厂实例，那么可以有更干净的解决方法。

我觉得create方法最好是工厂类的静态方法。 但我也确信我的观点并不完全“正确”。

那么 SO 社区能否举例说明实例化 Factory 对象比使用静态创建方法更好？

另外，我遇​​到了类似问题的答案，其中列出了这些链接和答案：所以我需要清楚地了解 FactoryMethodPattern、FactoryMethod 和 CreationMethod 以及代码示例。

Answer 1

使用工厂实例与依赖注入结合使用可以带来真正的好处。

因此，在您的示例中，而不是：

{ ...
    SomeFactory factory = new SomeFactoryImpl();
    Set<SomeClass> list = factory.getSomeListOfObjects();
}

您将：

public ThisClass(SomeFactory someFactory) {
    this.factory = someFactory;
}   

然后稍后...

{ ...
    Set<SomeClass> list = factory.getSomeListOfObjects();
}

几点：

• 在这种情况下，您的类没有对具体工厂的任何引用，并且不需要了解 SomeFactoryImpl，它只知道抽象的 SomeFactory。
• 在这种情况下，可以在实例的基础上配置正在传递的工厂实例，而不是静态的基础上，这往往是（在我看来）更好的处理方法。 如果您可以使工厂实例不可变，那么您就可以真正减少多线程的担忧。
• 通过静态调用来为您提供一个实例并不是真的更好，对创建它的类的引用仍然是一个具体的实现细节，它只是更高 - 尽管这可能使其足够高以解决您的问题。

我知道这只能解决你问题的一部分......

Answer 2

我想，用于创建对象的静态方法是最流行的方法，但也有一些用例首先创建工厂实例是有意义的。 例如，如果您想将其与注册表结合起来（应允许多个注册表共存）。

另外，如果工厂依赖于一些动态上下文信息（数据库连接等），我认为最好让工厂实例来处理这个问题。

Answer 3

首先你忘记了工厂模式的主要目的，我打开了四人帮的书，它写道：

“定义一个用于创建对象的接口，但让子类决定实例化哪个类。工厂方法让一个类将实例化推迟到子类。”

这意味着您实际上定义了一个接口，因此 SomeFactoryImpl 实际上应该实现在其他地方定义的接口。 当您有许多需要实例化的对象但您不想关心它们是什么类型的对象时，这会很方便。例如，我使用它们开发了一个远程 Swing 应用程序，其中客户端通过序列化下载客户端虚拟机中不存在的一些类的定义。 每个类都定义了 JPanel 的一个子类，它具有特定的视图，但是当到达客户端时，我必须找到一种方法来实例化这些类而不知道它们，所以我使用工厂模式来调用工厂类并让它实例化我的未知对象（尽管它正在扩展我定义的 JPanel 的子类）。
另一个例子是生成特定于案例的对象以满足您的需求。 例如（如与此设计模式相关的维基百科页面中所述），您可以认为一个工厂构建对象，然后是另一个构建同一类型对象的工厂，但用于生成“假对象”，这将无法通过某种单元测试。

但是，您也可以使用静态方法解决您的特定问题，但请考虑将生成项目的部分与在大项目中使用它们的部分分开。 当然，开发客户端部分的人应该只知道使用了哪个工厂接口，并且知道这一点才能使用其他部分中定义的所有对象。

创建模式是一种“工具”模式，仅用于定义构造函数的自定义版本，而不必担心使用标准定义（方法的名称等于类的名称），但它没什么特别的。 只是实例化对象的不同方式。创建模式实际上并不能解决任何类型的特定问题（不包括具有相同数量和类型参数的构造函数）。

Answer 4

这就是为什么我创建工厂对象的实例，

1. 它允许我创建一个工厂，配置它（创建蓝色小部件与红色小部件等），然后让它可根据需要创建我的蓝色小部件、红色小部件。 请注意，这与 RedWidgetFactory、BlueWidgetFactory 不同。 该配置与所创建的对象类型正交，
2. 它减少了在整个系统中使用一个工厂（通过静态方法访问）时可能遇到的线程问题。 这可能有点防御性，但我发现这是一个很好的心态（尤其是在大型系统中）。 当然，这取决于您的对象是如何创建的（例如，您的工厂是否创建共享的底层组件）

Answer 5

IMO，您拥有的代码确实是 GoF 的正确样本抽象工厂模式，即使它的使用并不完全优化。 如果我没记错的话，GoF 书描述了工厂（SomeFactory、SomeFactoryImpl）和产品（SomeClass）之间的关系，但没有提及实例化工厂的细节。

如果您拥有的是不会被广泛使用的内部 API，那么您拥有的可能就足够了。 否则，您可以：

1. 让另一个类（可以说是“工厂管理器”）根据参数（例如 JDBC 中的 DriverManager）或其他上下文信息选择工厂实现。
2. 使用某种依赖注入框架。

如果选择#1，我个人通常会尝试在 JDBC 之后对其进行建模，其中：

• Driver 将是抽象工厂
• Connections、Statements 等是products
• DriverManager （GoF 书中未明确指定）是一个实用程序类，它根据传入的 JDBC URL 为您选择一个工厂

（在本例中，DriverManager 继续执行）并为您创建产品，如果您像大多数人一样使用 getConnection(...) 方法。）

为了将其与您的问题联系起来，可以通过调用

new OracleDriver().connect(...)

But 作为您的方法 来使用 JDBC指出，这是次优的，并且在某种程度上违背了使用抽象工厂模式的目的。

这个问题曾经也让我很困扰，直到有一天我意识到该模式实际上并没有明确谈论工厂是如何创建的。

我希望这回答了你的问题。