工厂方法模式的好处

Question

我现在正在阅读Head First Design Patterns，我有一个问题。在书的开头，我看到了这个原则：

喜欢“对象组合”而不是“类继承”

然后我看到了工厂方法

abstract class Creator{
   abstract Product create(String type);
}

和子类

class ConcreteCreator extends Creator{
    Product create(String type){
     //creation
    }
}

但是我们可以用简单的工厂来组成我们的类，就像

class OurClass{
     SimpleFactory factory;
     void ourMethod(){
        Product product = factory.create(String type);
     }
     void setFactory(SimpleFactory factory){
        this.factory = factory;
     }

interface SimpleFactory {
     Product create(String type);
}

class AnotherConcreteCreator implements SimpleFactory {
     Product create(String type){
      //creation
     }
}

从第二种方法出发，给出了松耦合和可互换的方法。但是工厂方法是存在的，所以有人需要它。工厂法的优点是什么？

Answer 1

首先，区分工厂方法模式和抽象工厂模式是很重要的，关于这一点，请参见抽象工厂模式与工厂方法的区别、为什么有两个独立的模式:抽象工厂和工厂方法和工厂模式和抽象工厂模式的基本区别是什么？。正如你所看到的，这是一个有点棘手的问题，因此，我在下面所说的，必须采取的一粒盐。

特别是，我认为您的OurClass示例是抽象工厂模式的典型用例。更具体地说，抽象工厂模式使您可以灵活地使正在创建的具体对象类型成为类的参数，并且它的典型用例可以是依赖注入 (尽管这通常是以更自动化的方式完成的)，请参见依赖注入与工厂模式。

粗略地说，在抽象工厂模式中，您将对象的构造委托给外部类(通常，该类不仅负责创建一个相关对象，还负责创建多个相关对象)，而在工厂方法模式中，则将对象的构造委托给子类。您还可以认为抽象工厂模式使用工厂方法模式来创建方法。

因此，对于何时使用工厂方法模式的问题，一个简单的答案是:当创建对象是子类的响应时。这意味着，只有子类应该或能够决定需要创建什么对象，因此是子类行为的一个方面，这使我们回到最初的假设，并归结为一个问题:何时应该使用继承？，分别是喜欢构图而不是继承？。

另一方面，在描述抽象工厂模式的情况下，当外部因素决定需要创建哪些对象并需要这种灵活性时，可以使用抽象工厂模式，从而证明代码所需的额外复杂性是合理的。