工厂方法 - 应用程序类是否需要是抽象的？答案

【问题标题】：Factory method - Does application class need to be abstract?工厂方法 - 应用程序类是否需要是抽象的？
【发布时间】：2018-03-05 11:26:42
【问题描述】：

Erich Gamma 的 GOF 设计模式书说：

而 word application 可以自己创建多个文档，如下所示：

似乎一个应用程序可以创建多个文档。
在什么情况下，我需要将 Application 类抽象化，然后从中派生？

【问题讨论】：

从你的例子中我可以看到；每个案例都会有 Application abstract 因为 CreateDocument 不能通用
@Aquarius_Girl 在当前情况下，您可以拥有基于插件的设计，您可以在单独的插件类中创建文档。负责文档创建的 Base Plugin 类可以将 createDocument 作为抽象。你可以参考下面我的回答，希望对你有帮助。
你怎么知道 Word 使用工厂方法模式？
@Aquarius_Girl 还是有一些不清楚的地方，我们可以再想办法解决不清楚的地方

标签： design-patterns factory factory-pattern

【解决方案1】：

应用类抽象不是工厂模式的本质，但我们需要看到它背后的意图。抽象插件类（在下面的示例实现中）实现了相同的意图。

任何将对象创建推迟到其需要处理的对象的子类的类都可以视为工厂模式的示例。

GOF 中描述的工厂模式提供了一个文档应用程序的可能实现示例，以供理解，但不特定于特定的 Word 应用程序，但我们仍然可以有一个可能的基于 factory method 的设计

对于当前的 Word 应用程序，可能的设计类似于基于插件的设计，我们可以有多个插件，每个插件都可以添加到应用程序中。实体（在本例中为文档）创建由每个插件完成。

如果需要新类型的文档，则可以实现插件并将其添加到应用程序中。

代码的可能结构如下所示。

Class Application{
    List<Plugin> plugins ;
    public void addPlugin(Plugin newPlugin){
       plugins.add(newPlugin);
    }
    //more code as per req and features
}

 public abstract class Plugin{
    public abstract Document createNewDocument();
    public void openNewDocument(){
         Document doc = createNewDocument();
         doc.open();// assuming open is a method in Document interface.
           //more code as per req and features
    }
 }

public class PNGPlugin extends Plugin{
     public Document createNewDocument(){
          return new PNGDocument();// Document being the interface for various documents.
     }
       //more code as per req and features
}

当前方法中的菜单项将取决于插件列表。

【讨论】：

那么，你现在实现的word文档也是工厂方法的例子吗？
是的，插件基类是我实现中的工厂类
目前可能支持n数量的可能插件，以后可以实现更多。文档创建被分解到插件类的每个实现
插件基类需要打开文档，但希望将文档实现类型推迟到插件类的实际实现。在这种情况下，它可以通过依赖于文档接口并调用文档接口声明的open() 方法来执行此操作（打开文档）。为了获取实际对象，它将其推迟到由具体插件类实现的抽象方法 createDocument()。
请给我一些时间再次阅读您的答案。感谢您的耐心等待。

【解决方案2】：

常见的情况是 Application 和 Document 抽象类由您使用的框架（例如 Swing、UIKit 或 Gnome）提供，而您自己的代码会将它们实现为 MyDocument 和 MyApplication。

【讨论】：