java - 作为接口(interface)实现的抽象工厂模式

Question

我对抽象工厂模式很好奇。从 Java 8 开始，我们有了默认方法，这是否意味着我们可以将我们的抽象类替换为接口(interface)？我可以看到的一个缺点是我们需要非静态/最终字段的情况。我们不能做接口(interface)。老式工厂在什么情况下更有优势，您能举几个例子吗(我举的这个除外)？

Answer 1

技术上你可以，但你不应该。

接口(interface)上的默认实现是一种具有一些非常特定目的的工具 - 主要用于向很可能已由您控制之外的客户端实现的接口(interface)添加功能，或者用于已重复实现的接口(interface)，默认实现将很难重新实现。

当您从一些共同父类的行为中扩展时，它们不旨在替代(甚至补充)抽象类。

也就是说，抽象工厂模式 与 Java 对 abstract 关键字的使用关系不大。抽象工厂模式是关于隐藏(或抽象掉)给定客户端实际用于生成对象的具体工厂实现。工厂的工厂方法被定义为返回的可能是具体类，也可能是抽象类，也可能是接口(interface)。

所以，例如-

假设你有一些类，GuiPainter。它有一个方法，#paintWindow。

在幕后，您已经引入了一个 Window，它具有特定于操作系统的实现，例如 AppleWindow、AndroidWindow、UbunutuWindow(等等)。每个 Window 实现在构建方式上都略有不同。

一种方法是使用 AppleWindowFactory、AndroidWindowFactory、UbuntuWindowFactory(等等)构建 GuiPainter，以及找到操作系统和决定使用哪个工厂的方法。然而，GuiPainter 真正想要的只是 Window 的任何实例——它没有其他特定于操作系统的知识。

因此，我们改为引入 WindowFactory，它返回一个 Window。 WindowFactory 是一个工厂，它具有发现操作系统和决定使用哪个具体窗口工厂的知识 - 从 GuiPainter 中抽象出该责任。

Window 本身可能是一个具有单一实现的具体类，只是基于操作系统的配置差异。它可能是一个具有操作系统特定实现(如 AppleWindow、AndroidWindow 等)的抽象类。它甚至可能是由工厂匿名实现的接口(interface)。 Window 是什么并没有改变，客户端不再需要担心操作系统特定的废话来获得它想要的窗口。

这有意义吗？