相对于工厂方法模式和抽象工厂模式，简单工厂模式有哪些缺点？

Question

Head First Design Patterns 将 Simple Factory 描述为：

public class SimplePizzaFactory {
    public Pizza createPizza(String type) {
        Pizza pizza = null;
        if (type.equals(“cheese”)) {
            pizza = new CheesePizza();
        } else if (type.equals(“pepperoni”)) {
            pizza = new PepperoniPizza();
        } else if (type.equals(“clam”)) {
            pizza = new ClamPizza();
        } else if (type.equals(“veggie”)) {
            pizza = new VeggiePizza();
        }
        return pizza;
    }
}

与工厂方法模式和抽象工厂模式相比，简单工厂模式有什么缺点？

在Gamma等人的《设计模式》一书中，工厂方法模式中的基于类的参数化工厂方法似乎与简单工厂类似。参数化的抽象工厂是否正是简单工厂？《设计模式》是否提到了参数化的抽象工厂？

- Tim

---

工厂方法适用于代码永远不会改变的情况（例如，Guava的Collections2.newLinkedList()在我编写的所有应用程序中都没有更改）。简单工厂适用于您想要添加新结果的情况，但对象的构建大部分相同。抽象工厂适用于整个构建过程根据所得到的对象的实际实现而变化的情况。 - PEdroArthur

Answer 1

与工厂方法模式和抽象工厂模式相比，简单工厂模式的缺点是什么？

将工厂方法模式与抽象工厂模式进行比较并不完全正确，因为它们有不同的用途。工厂方法只是创建一个对象，而抽象工厂模式则通过定义一个接口来创建一组对象。如果我没记错的话，这两个模式都在你正在阅读的书中有描述。

回到简单工厂与工厂方法的缺点：谈论设计模式时，关键在于如何应用它们解决具体问题，并且因情况而异。

为每个要创建的对象类型都拥有一个工厂类可能会使您的代码变得复杂，每个对象系列将在附近拥有一个工厂类，因此很快您的代码就会爆炸出现“工厂”类。如果应用正确，则这是我所知道的唯一缺点。当然，另一方面，工厂方法也有其缺点。在二者之间选择时，我总是问自己谁是代码的客户端，对他来说哪种更容易使用。

在《设计模式》（Gamma等人）中，工厂方法模式中的类参数化工厂方法似乎与简单工厂相似。参数化抽象工厂是否确切等同于简单工厂？《设计模式》是否提到了参数化抽象工厂？

不完全正确，但是AbstractFactory的具体工厂实现看起来确实像简单工厂。

我建议您也阅读其他文章，我的个人偏好是Zoran在抽象工厂上的帖子和讲座。查看样例：http://codinghelmet.com/articles/cascading-abstract-factories

- Dan Dinu

Answer 2

简单工厂是为一个类拥有一个创建方法的工厂类。该方法含有一个大型条件语句，根据方法参数选择要实例化的产品类（简单工厂不是设计模式）。

简单工厂示例：

class UserFactory {
public static function create($type) {
    switch ($type) {
        case 'user': return new User();
        case 'customer': return new Customer();
        case 'admin': return new Admin();
        default:
            throw new Exception('Wrong user type passed.');
    }
}

}

- NTIC TECH