抽象工厂模式有规模吗？

Question

我仍然试图在这里理解设计模式，在学习了抽象工厂模式之后，我意识到这个模式不会很好地扩展。查看抽象工厂模式的uml图。

如果我必须创建一个新的'AbstractProductC'，我将不得不在'AbstractFactory‘中添加一个抽象方法’AbstractFactory‘，这将影响ConcreateFactory1，ConcreateFactory2的实现。

我的问题是，抽象工厂模式量表(或者)，我在这里想错了方向吗？

提前感谢

Answer 1

抽象工厂的规模很好。

有一个基本原则，那就是一个类应该做好一件事。你的问题是，你试图让许多类做很多事情。

你不需要坚持一个抽象的工厂。您可以(而且应该)拥有以下几个：

AbstractProductAFactory定义了生成ProductA的接口。您的具体实现(ConcreteProductAFactory1、ConcreteProductAFactory2)将对其进行扩展。

AbstractProductBFactory定义了生成ProductB的接口。您的具体实现(ConcreteProductBFactory1、ConcreteProductBFactory2)将对其进行扩展。

如果然后需要一个ProductC，那么创建一个新的AbstractProductCFactory。没有必要这样改变你的其他工厂。

理想情况下，ProductA应该代表一类产品--也就是说，所有共享您所调用的ProductA接口的产品。在评论中，我认为这有点像必胜客：

interface AbstractPizzaFactory {
    public Pizza buildPizza(List<Topping> toppings);
}


class ThinCrustPizzaFactory implements AbstractPizzaFactory {
    public Pizza buildPizza(List<Topping> toppings){

        ...

    }
}

class DeepDishPizzaFactory implements AbstractPizzaFactory {
    public Pizza buildPizza(List<Topping> toppings){

        ...

    }
}

诸若此类。添加PanPizzaFactory不会影响任何其他类--它只是PizzaFactory的一个新的具体实现。如果你的产品不是披萨--比如三明治，那就是你创建另一个抽象工厂的地方(例如，AbstractSandwichFactory)。

真正的问题是，您不希望有一个抽象工厂用两种不同的“构建”方法构建两种非常不同类型的产品。尽可能从逻辑上对它们进行分组，以便它们共享接口，然后创建一个抽象工厂，该工厂定义具体工厂应该如何构建该接口的实现。

Answer 2

缩放的问题是，代码可以以许多不同的方式进行扩展。您所遇到的问题仅仅是由于需要向某个方向扩展而引起的，这种设计模式并不是有意的。在抽象工厂模式的情况下，它的规模是以增加新的混凝土工厂的方式进行的，但是添加新产品会导致结构上的大变化。

软件设计和体系结构的要点之一是确定最有可能的方向，代码将根据这些可能的方向伸缩和选择模式。如果您认为添加新产品比添加新的混凝土工厂更有可能，那么使用抽象工厂并不是一个好主意，最好完全重新考虑设计。

Answer 3

是的，你是对的，当你需要额外的抽象产品时，“抽象工厂”的规模并不大。

但是在很多真实世界的场景中，你有一个不断变化的产品数量，但是只有少量的固定数量的抽象产品可以支持。例如，以维基百科关于抽象工厂的文章中的GUI小部件为例。抽象GUI工厂可以有一个方法createWidget (而不是createButton)，其中Widget是“抽象产品”，是几十个GUI元素家族的最顶层基类。添加新的GUI小部件绝不意味着对抽象工厂的界面进行更改，因此不必更改具体工厂的任何界面。

拥有大量的抽象产品意味着代码中将有许多不同的类层次结构。如果是这样的话，您可以考虑为每个层次结构创建一个单独的工厂(或抽象工厂)。