为什么 C# 允许没有抽象成员的抽象类？

Question

C# 规范 第 10.1.1.1 节 规定：

允许使用抽象类（但是 不需要）包含摘要 成员。

这允许我创建这样的类：

public abstract class A
{
    public void Main() 
    {
        // it's full of logic!
    }
}

或者甚至更好：

public abstract class A
{
    public virtual void Main() { }
}

public abstract class B : A
{
    public override sealed void Main()
    {
        // it's full of logic!
    }
}

这确实是一个具体的类；它只是抽象的，因为人们无法实例化它。例如，如果我想执行 B.Main() 中的逻辑，我必须首先获取 B 的实例，这是不可能的。

如果继承者实际上不必提供实现，那么为什么称其为抽象呢？

换句话说，为什么 C# 允许只有具体成员的抽象类？

我应该提到的是，我已经熟悉抽象类型和成员的预期功能。

Answer 1

也许一个很好的例子是公共基类，它为派生类提供共享属性和其他成员，但不表示具体对象。例如：

public abstract class Pet
{
    public string Name{get;set;}
}

public class Dog : Pet
{
    public void Bark(){ ... }
}

所有的宠物都有名字，但宠物本身是一个抽象的概念。宠物的实例必须是狗或其他某种动物。

此处的区别在于，基类声明所有宠物至少由一个 Name 属性组成，而不是提供应由实现者重写的方法。

Answer 2

这个想法是强制实现者从类派生，因为它的目的只是为可能更专业的实现提供基础。因此，基类虽然没有任何抽象成员，但可能只包含核心方法和可用作扩展基础的属性。

例如：

public abstract class FourLeggedAnimal
{

    public void Walk()
    {
        // most 4 legged animals walk the same (silly example, but it works)
    }

    public void Chew()
    {

    }
}

public class Dog : FourLeggedAnimal
{
    public void Bark()
    {
    }
}

public class Cat : FourLeggedAnimal
{
    public void Purr()
    {
    }
}

Answer 3

我认为对你的问题的更准确的表述是：为什么 C# 允许一个只有具体成员的抽象类？

答案是：没有充分的理由不这样做。也许有人有某种组织结构，他们喜欢在顶部有一个不可实例化的类，即使它下面的类只是继承并且不添加任何内容。没有充分的理由不支持这一点。

Answer 4

你这么说——因为你无法实例化它；它只是一个模板。

如果您将其声明为抽象类，那么它就不是“真正的具体类”。您可以将其作为设计选择。

这种设计选择可能与创建实体有关，这些实体是现实世界对象的抽象（存在术语混合的风险），并且具有可读性。您可能想要声明 Car 类型的参数，但不希望将对象声明为 Car ——您希望每个对象都是 Car 类型> 实例化为 Truck、Sedan、Coupe 或 Roadster。事实上，Car 不要求继承者添加实现，这一事实并不会降低其作为其继承者的抽象版本（本身无法实例化）的价值。

Answer 5

抽象意味着提供行为的抽象。例如，Vehicle 是一种抽象形式。它没有任何现实世界的实例，但我们可以说车辆具有加速行为。更具体地说，福特 Ikon 是一种车辆，雅马哈 FZ 是一种车辆。这两者都有加速行为。

如果你现在在课堂上做这个。 Vehicle 是具有 Acceleration 方法的抽象类。虽然您可能/可能不提供任何抽象方法。但业务需求是Vehicle不应该被实例化。因此你把它变得抽象。另外两个类 - Ikon 和 FZ 是从 Vehicle 类派生的具体类。这两者将有自己的属性和行为。

Answer 6

关于用法，在类声明上使用 abstract 但没有抽象成员与使用 public 类但在其类上使用 protected 是一样的构造函数。两者都强制派生类以便实例化它。

然而，就自记录代码而言，通过标记类abstract，它会告诉其他人该类永远不会自行实例化，即使它没有virtual code> 或 abstract 成员。而保护构造函数则没有做出这样的断言。

Answer 7

编译器不会阻止实现逻辑，但在你的情况下我会简单地省略 abstract ？！顺便说一句，一些方法可以用 { throw Exception("must继承"); 来实现} 并且编译器无法区分完全实现的类和函数，仅包括抛出。

Answer 8

这是一个潜在的原因：

图层超类型

对于所有对象来说这并不罕见
在一个层中拥有你没有的方法
想要在整个过程中重复
系统。你可以移动这一切
行为到公共层
超级类型。

-- 马丁·福勒

没有理由阻止抽象类中只包含具体方法 - 只是不太常见。 Layer Supertype 是一种可能有意义的情况。

Answer 9

我认为抽象类有两个主要用途：

• 一个不完整的类，必须专门提供一些具体的服务。在这里，抽象成员是可选的。该类将提供一些子类可以使用的服务，并且可以定义用于提供服务的抽象成员，例如 模板方法模式。这种类型的抽象类旨在创建一个继承层次结构。

• 仅提供静态实用方法的类。在这种情况下，抽象成员根本没有意义。 C# 通过 静态类< /a>，它们是隐含的抽象和密封的。这也可以通过带有私有构造函数的密封类来实现。