例如：http://www.tutorialspoint.com/design_pattern/factory_pattern.htm
如果我在抽象类Shape上更改界面形状，则使具体类扩展Shape并使Shape工厂返回Shape抽象类类型对象。它仍然是工厂模式吗？
答案 0 :(得分：4)
我会选择是。
让我们看一下Factory方法模式的定义：
工厂方法模式是创建模式，它使用工厂方法来处理创建对象的问题，而不指定将要创建的对象的确切类
此模式背后的动机是使用对象将对象创建与客户端分开。客户应该向工厂提供规范，但详细说明对象的构建方式是由工厂抽象出来的。
如果这是一个接口或抽象类是一个特定于情况的实现细节，只要你的工厂实现让你实现模式背后的动机。
如果这些陈述中的任何一个适用于您的情况，请考虑使用抽象类：
您希望在几个密切相关的类之间共享代码。
您希望扩展抽象类的类具有许多常用方法或字段，或者需要除公共之外的访问修饰符（例如protected和private）。
您想要声明非静态或非最终字段。这使您可以定义可以访问和修改它们所属对象状态的方法。
如果这些陈述中的任何一个适用于您的情况，请考虑使用接口：
您希望不相关的类能够实现您的界面。例如，Comparable和Cloneable接口由许多不相关的类实现。
您希望指定特定数据类型的行为，但不关心谁实现其行为。
您希望利用类型的多重继承。
在某些实现中，使用抽象类而不是工厂创建的产品的接口甚至更有意义。如果所有产品之间存在共享的功能/行为集，那么将它们放入基本抽象类中是有意义的。即使产品是从不同的工厂生产的，这也适用。
归结为：你希望并且引入耦合是否有意义 产品之间或不？ 最后，客户将获得相同的结果 - 根据规范构建产品，并将结构细节抽象出去。
答案 1 :(得分：1)
当谈到这些差异时，答案总是既可以也可以是肯定的。设计模式不是任何精确的规范，它们更像是一组最佳和推荐的实践，它们的实现因具体情况而异。
在我看来答案是否定的，从技术上讲，这不是工厂模式。并且它不一定是，只要它解决了您的用例并使代码可读和可维护（试图从字面上坚持设计模式经常导致滥用它们和过度架构）。
如果我们查看抽象工厂模式（位于链接页面中的工厂模式下方），我们将看到它是一个用于创建工厂的工厂。现在假设我们有两个Shape工厂可以由AbstractFactory：ShapeFactory2D和ShapeFactory3D创建，两者都生成Shape个对象。
如果Shape是抽象类，那么你会强制2D和3D对象继承相同的实现，尽管它可能没有意义（它们可以以完全不同的方式实现）。
因此，从技术上讲，为了使其真正成为工厂模式，必须不存在关于实现细节的假设，这意味着不应在工厂接口级别使用包含部分实现的抽象类。
当然，您可以使用Abstract2DShape和Abstract3DShape个抽象类来实现Shape;关键是你能够创建和使用 Shape而不知道它是2D还是3D形状。