理解工厂方法模式

Question

我正在读一篇关于工厂方法模式的文章。

我可以理解何时有一个工厂类，即StoreFactory#getStore()，根据某个运行时或其他状态返回Store实现。

但是，从阅读(例如this link)来看，似乎有一种通用的模式，人们创建一个抽象的工厂类，其他工厂类扩展到这个抽象工厂类：

 public abstract class AbstractFactory {
     public abstract Store getStore(int store);
 }

 public class StoreFactoryA extends AbstractFactory {
     public Store getStore(int Store) {
         if(Store == 1) { return new MyStoreImplA(); }
         if(Store == 2) { return new MyStoreImplB(); }
     }
 }

 public class StoreFactoryB extends AbstractFactory {
     public Store getStore(int Store) {
         if(Store == 1) { return new MyStoreImplC(); }
         if(Store == 2) { return new MyStoreImplD(); }
     }
 }

 public class Runner {
    public static void main(String[] args) {
        AbstractFactory storeFactory = new StoreFactoryA();
        Store myStore = storeFactory.getStore(1);
    }
 }

我的例子是人为设计的，但模拟了前面提到的链接。

对我来说，这个实现看起来像是一个鸡蛋。使用工厂方法模式来消除客户端代码指定类类型的需要，但是现在客户端代码需要有选择地选择要使用的正确工厂，即StoreFactoryA、StoreFactoryB

在这里使用抽象类背后的原因是什么？

Answer 1

不幸的是，您正在阅读的链接并没有给出该模式的实际示例。事实上，根据最初的GoF设计模式，这种模式被称为抽象工厂方法(是另一种模式)。

当您拥有能够创建对象的系列的工厂时，就会使用抽象工厂模式。例如，你可以有和AbstractGUIFactory，它们可以有createButton(), createWindow(), createTitleBar等方法。然后，你会有像WindowsGUIFactory, MacGUIFactory, MotifGUIFactory等具体的工厂，每个工厂都会以自己的方式产生Button, Window, TitleBar对象。

工厂将在应用程序中的某个时刻设置为一个实现(可能使用配置)，然后在需要创建对象的任何地方都将使用该工厂。

如果你正在学习设计模式，最好的建议是从经典的GoF书籍开始。

Answer 2

这个模式变得很有趣，尤其是在进行测试时。现在，您可以将AbstractFactory注入到类中，并为不同的环境或测试选择不同的类型，而无需更改类(如果工厂创建共享公共接口的类型)。

使用类不必依赖于工厂的具体实现，也不必依赖于所创建类型的实际实现。

Answer 3

使用Factory方法时，该方法仍在对象中，您需要实例化正确的对象才能访问该方法。您实现的唯一抽象是因为Abstract类。

工厂方法模式就是这样设计的。也许，您希望它类似于Abstract Factory模式，它比Factory方法具有更好的抽象。

http://c2.com/cgi/wiki?AbstractFactoryVsFactoryMethod