例如：http://www.tutorialspoint.com/design_pattern/factory_pattern.htm

如果我更改抽象类形状上的接口形状，则使具体类扩展形状，并使形状工厂返回形状抽象类类型化对象。它还会是工厂模式吗？

我同意。

让我们看看工厂方法模式的定义：

the factory method pattern is a creational pattern which uses factory methods to deal with the problem of creating objects without specifying the exact class of object that will be created

号

此模式背后的动机是将对象创建与使用对象的客户机分离。客户机应该向工厂提供规范，但是工厂会抽象出如何构建对象的细节。

如果这是一个接口或抽象类，是一个特定于具体情况的实现细节，只要您的工厂实现允许您实现模式背后的动机。

如果这些语句中的任何一个适用于您的情况，请考虑使用抽象类：

• You want to share code among several closely related classes.

• You expect that classes that extend your abstract class have many common methods or fields, or require access modifiers other than public (such as protected and private).

• You want to declare non-static or non-final fields. This enables you to define methods that can access and modify the state of the object to which they belong.

号

如果这些语句中的任何一个适用于您的情况，请考虑使用接口：

• You expect that unrelated classes would implement your interface. For example, the interfaces Comparable and Cloneable are implemented by many unrelated classes.

• You want to specify the behavior of a particular data type, but not concerned about who implements its behavior.

• You want to take advantage of multiple inheritance of type.

号

在某些实现中，使用抽象类甚至可能更有意义，而不是工厂创建的产品的接口。如果所有产品之间都有一组共享的特性/行为，那么将它们放入基本抽象类是有意义的。即使产品是从不同的工厂生产的，这也适用。

归根结底就是：你想这样做吗？引入耦合是否有意义？是否在产品之间？最后，客户将得到相同的结果——基于规范构建的产品，并将构建细节抽象出来。

当涉及到这些差异时，答案总是可以是肯定的，也可以是否定的。设计模式不是任何一种精确的规范，它们更像是一组最佳和推荐的实践，它们的实现因情况而异。

在我看来，答案是否定的，从技术上讲，这不是工厂模式。而且，只要它解决了您的用例并使代码可读和可维护，它就不一定是这样的(试图严格遵循设计模式往往会导致误用它们和过度架构)。

如果我们查看抽象工厂模式(链接页面中工厂模式的正下方)，我们将看到它是用于创建工厂的工厂。现在假设我们有两个可以由AbstractFactory创建的Shape工厂：ShapeFactory2D和ShapeFactory3D，它们都生成Shape对象。

如果Shape是抽象类，那么您将强制二维和三维对象继承相同的实现，尽管这可能毫无意义(它们可以以完全不同的方式实现)。

因此，从技术上讲，为了使其真正成为工厂模式，必须不存在关于实现细节的假设，这意味着包含部分实现的抽象类不应在工厂接口级别使用。

当然，您可以让Abstract2DShape和Abstract3DShape抽象类实现Shape；重点是您可以创建和使用Shape，而不必知道它是二维还是三维形状。