java中的工厂模式

jrh*_*ath 5 java design-patterns factory-pattern

我正在使用据称使用Factory模式的java代码,但我并不完全相信这种模式.

我的代码执行此操作:

// the factory
class SomeFactoryImpl {
   Set<SomeClass> getSomeListOfObjects();
}
Run Code Online (Sandbox Code Playgroud)

在代码的某处:

{ ...
    SomeFactory factory = new SomeFactoryImpl();
    Set<SomeClass> list = factory.getSomeListOfObjects();
}
Run Code Online (Sandbox Code Playgroud)

我正在思考的一点是,如果工厂类没有静态的create()方法,那么就需要实例化一个工厂,IMO应该像实例化一个对象一样复杂.

我不认为这样的工厂可以返回要生成的对象集合的论点已经足够了.如果在从工厂实际创建对象之前需要创建工厂实例,我觉得可以有更清晰的解决方法.

我觉得如果create方法是工厂类的静态方法,那就更好了.但我也确信我的观点并不完全"正确".

那么SO社区可以举例说明实例化Factory对象比使用静态创建方法更好吗?

另外,我遇​​到了一个类似问题的答案,其中列出了这些链接和答案:所以我需要清楚地了解FactoryMethodPattern,FactoryMethodCreationMethod与代码示例之间的区别.

Gru*_*eck 5

使用工厂实例显示与依赖注入相结合时的真正好处.

所以在你的例子中,而不是:

{ ...
    SomeFactory factory = new SomeFactoryImpl();
    Set<SomeClass> list = factory.getSomeListOfObjects();
}
Run Code Online (Sandbox Code Playgroud)

你将会拥有:

public ThisClass(SomeFactory someFactory) {
    this.factory = someFactory;
}   
Run Code Online (Sandbox Code Playgroud)

然后......

{ ...
    Set<SomeClass> list = factory.getSomeListOfObjects();
}
Run Code Online (Sandbox Code Playgroud)

一些要点:

  • 在这种情况下,你的类没有任何对具体工厂的引用,也不需要知道SomeFactoryImpl,它只知道抽象的SomeFactory.
  • 在这种情况下,传递的工厂实例可以基于实例进行配置,而不是静态基础,这往往(在我看来)是一种更好的处理方式.如果您可以使工厂实例不可变,那么您可以真正减少多线程的担忧.
  • 有一个静态调用给你一个实例并不是真的好多了,对创建它的类的引用仍然是一个具体的实现细节,它只是更高 - 虽然这可能使它足够高,可以解决你的问题.

我知道这只涉及你问题的一个子集......