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