C# 为什么抽象工厂使用抽象类而不是接口？

我正在学习设计模式，书中的第一个例子是关于抽象工厂。 我已经在VS中构建了这个练习，看起来都不错，但是有一个问题我想知道

在本书中，factory类的实现方式如下：

public abstract class AbstractVehicleFactory
{
    public abstract IBody CreateBody();
    public abstract IChassis CreateChassis();
    public abstract IGlassware CreateGlassware();
}

完成练习后，我注意到上述类别可替换为以下代码：

public interface IAbstractVehicleFactory
{
      IBody CreateBody();
      IChassis CreateChassis();
      IGlassware CreateGlassware();
}

---

当然，两个示例的功能完全相同，但我想知道使用抽象类而不是接口的原因是什么？

这可能是书中的一个拼写错误，第一个“接口”实际上是一个抽象类

---

没有所谓的“抽象接口”。根据定义，接口是抽象的。

接口确实是实现这一点的最优雅的方式

使用抽象类的参数：有时，当类维护状态并且某些部分已经已知时，使用抽象类可能很有用

---

但是，更安全的做法是首先使用接口，然后选择性地实现引入这种状态的抽象类。由于

C#

只允许单一继承，当

ConcreteFactory

应该从不同的类继承时，可能会遇到麻烦。

一个抽象类可以谨慎地以不中断的方式扩展；对接口的所有更改都是破坏性更改

更新：
相反，接口可以是In或out类型参数，而抽象类不能。有时一个或另一个更适合于给定的设计，有时这是一个折腾。

中的“抽象”与

抽象类中的“抽象”无关。抽象工厂是具体工厂的“基础”，但设计模式本身并不强制任何特定的实现。抽象工厂可以是抽象的，甚至是具体的类、接口或鸭子类型对象的某种形式，具体取决于您使用的语言

事实上，在C#
接口中
是非常合理的指定抽象工厂的方法。
对，我的错！在创建这个问题时，我把类/接口搞混了。但是如果我使用接口，这不是“打破”了最初的设计模式吗？我的印象是，使用DP的目的是为了保持一致性。据我所知并非如此。在像
C++
这样允许多重继承的语言中，人们可能会争辩说接口不存在。设计模式仅仅是指导如何构造代码的准则。如果字段应该是私有的还是公共的，那么它们并没有一个正式的描述，不管您是应该使用接口还是抽象类。。。