Question

来自GoF的设计模式

抽象工厂

意图

提供用于创建相关或从属对象族的接口，而无需指定其具体类。

动机

考虑支持多种外观的用户界面工具包   标准，如Motif和Presentation Manager。不同   外观为用户定义不同的外观和行为   界面“小部件”，如滚动条，窗口和按钮。要成为   可以通过外观标准移植，应用程序不应该   为特定的外观和感觉硬编码其小部件。实例化   整个应用程序中特定于外观的小部件类   这使得以后很难改变外观。

我们可以通过定义一个抽象的WidgetFactory类来解决这个问题   声明了一个用于创建每种基本类型的小部件的接口。   每种小部件都有一个抽象类，并且   具体的子类为特定的外观实现小部件   标准。 WidgetFactory的接口有一个返回a的操作   每个抽象小部件类的新小部件对象。客户称之为   获取小部件实例的操作，但客户端不知道   他们正在使用的具体课程。因此客户保持独立   流行的外观和感觉。

我想知道以下是什么意思：

要在外观标准之间移植，应用程序应该不是硬编码其特定外观的小部件。

和

在整个应用程序中实例化特定于外观的小部件类使其难以更改后来的外观。

特别是，不使用抽象工厂类，代码是什么样的，为什么它不好？感谢。

Answer 1

当代码中的某些内容要求窗口小部件（比如窗口）时，not to hardcode表示您不应该这样做：

var window = new DesktopWindow()

大概你在很多地方创造了窗户，所以你会说，这些窗户创造了100个。如果您执行了上述操作，则会对应用程序进行硬编码以使桌面窗口无处不在。然后，如果你想要一个移动版本（或其他一些外观），你将不得不修改所有100个地方做这样的事情：

if(environment.IsMobile){
  window = new MobileWindow();
} else {
  window = new DesktopWindow();
}

窗口创建的逻辑越复杂，上面的代码就会变得越来越难。最终会有大量重复的代码执行相同的操作，使其难以维护。这是makes it hard to change look and feel later部分的含义。

使用抽象工厂，您的代码不关心它获取的窗口：

IWindow window = windowFactory.Create();

并且工厂实际上根据上下文知道要返回的窗口。调用者只使用公共接口IWindow来实现其目标。 Factory通过将创建逻辑保持在一个位置来简化代码，并且可以更轻松地添加新的Window类型（外观和感觉）。

我如何理解抽象工厂的动机？

1 个答案: