C#的abstract关键字是什么意思？怎么定义抽象类？-小浪学习网

抽象类不能实例化，用于定义必须由子类实现的抽象成员，同时可包含具体实现，强制契约并共享代码，适用于“is-a”关系和需部分实现的场景。

C#的abstract关键字是什么意思？怎么定义抽象类？

C#中的

abstract

关键字，说白了，就是用来声明一个东西是“抽象的”、“不完整的”或者“概念性的”。当它修饰一个类时，表示这个类不能直接被实例化，它更像是一个蓝图或者一个约定，必须由它的非抽象子类来具体化。如果它修饰一个方法、属性、事件或索引器，则意味着这个成员只有声明没有具体的实现，其实现细节必须由继承它的非抽象子类来提供。

定义抽象类很简单，你只需要在

class

关键字前面加上

abstract

修饰符就可以了。

解决方案

abstract

关键字在C#中扮演着一个非常重要的角色，它强制实现一种“契约”或者“规范”。一个被

abstract

修饰的类，我们称之为抽象类。抽象类可以包含抽象成员（如抽象方法、抽象属性），也可以包含非抽象成员（有具体实现的方法、字段、属性等）。

抽象类的核心特性：

不能直接实例化： 你不能使用
```
new
```
关键字直接创建抽象类的对象。因为它本身就是不完整的，就像你不能直接“实例化”一个“概念”一样。
可以包含抽象成员： 抽象类可以声明抽象方法、抽象属性、抽象事件和抽象索引器。这些抽象成员只有签名，没有方法体（用分号结束）。
可以包含非抽象成员： 抽象类也能拥有普通的方法、属性、字段和构造函数。这使得抽象类在提供公共基础功能的同时，又能强制子类实现特定的行为。
必须被继承： 抽象类的主要目的是作为基类，供其他类继承。
子类责任： 任何继承自抽象类且自身不是抽象类的子类，都必须使用
override
关键字实现其所有继承的抽象成员。如果子类没有实现所有抽象成员，那么这个子类也必须被声明为抽象类。

如何定义一个抽象类和抽象成员：

// 定义一个抽象类 public abstract class Vehicle {     // 抽象属性：所有车辆都有一个抽象的马力，具体数值由子类决定     public abstract int Horsepower { get; set; }      // 抽象方法：所有车辆都有一个启动引擎的方法，但具体启动方式不同     public abstract void StartEngine();      // 非抽象方法：所有车辆都有一个通用的显示信息方法     public void DisplayInfo()     {         Console.WriteLine("This is a vehicle.");     }      // 抽象类可以有构造函数，供子类调用     public Vehicle()     {         Console.WriteLine("Vehicle constructor called.");     } }  // 继承抽象类并实现抽象成员 public class Car : Vehicle {     private int _horsepower;      // 实现抽象属性     public override int Horsepower     {         get { return _horsepower; }         set { _horsepower = value; }     }      // 实现抽象方法     public override void StartEngine()     {         Console.WriteLine("Car engine started with a roar!");     }      public Car(int hp)     {         Horsepower = hp;     } }  // 另一个子类 public class Motorcycle : Vehicle {     private int _horsepower;      public override int Horsepower     {         get { return _horsepower; }         set { _horsepower = value; }     }      public override void StartEngine()     {         Console.WriteLine("Motorcycle engine sputtered to life.");     }      public Motorcycle(int hp)     {         Horsepower = hp;     } }

在实际应用中，当我需要定义一组紧密相关的类，它们共享一些公共特性和行为，但某些特定行为又必须由每个具体子类自行实现时，我通常会考虑使用抽象类。它提供了一个很好的平衡点：既能共享代码，又能强制实现特定接口。

为什么我们需要抽象类？它的实际应用场景有哪些？

我们之所以需要抽象类，很大程度上是因为它帮助我们更好地进行面向对象设计，尤其是在构建复杂系统时。在我看来，抽象类就像是设计蓝图中的“半成品”——它规定了框架，但把一些关键的、多变的细节留给具体的实现者。

核心原因：

强制契约与一致性： 抽象类最显著的特点就是它的“强制性”。当你定义一个抽象方法时，你就是在告诉所有继承这个抽象类的非抽象子类：“你必须实现这个方法，没有商量的余地！”这对于维护代码的一致性非常有用，尤其是在一个团队协作的项目中，它能确保所有相关的组件都遵循相同的行为规范。比如，我有一个
```
Logger
```
抽象类，里面定义了
```
LogInfo()
```
和
```
LogError()
```
抽象方法，那么无论是
```
FileLogger
```
还是
```
DatabaseLogger
```
，都必须实现这两个方法，这样我们就能统一地调用日志功能。
避免不完整对象的实例化： 有些概念本身就是抽象的，不应该被直接实例化。例如，一个
```
Shape
```
（形状）类，它本身没有具体的面积或周长，只有当它是一个
```
Circle
```
或`
```
Rectangle
```
时才有意义。将
```
Shape
```
定义为抽象类，就能防止开发者无意中创建出一个“没有具体形状”的
```
Shape
```
对象，从而避免逻辑错误。
共享通用实现： 抽象类与接口不同，它可以包含具体的实现代码（非抽象方法、字段、构造函数）。这意味着，如果多个子类共享一些共同的逻辑或状态，你可以把这些共同的部分放在抽象基类中实现，从而避免代码重复。这在实际项目中非常常见，比如一个抽象的
```
BaseController
```
，它可能包含了所有控制器都需要的一些认证或日志逻辑。
多态性基础： 尽管接口也是实现多态的一种方式，但抽象类同样是多态的基石。你可以用抽象类类型的引用来指向它的任何一个具体子类的实例，从而实现运行时行为的动态绑定。这让代码更加灵活和可扩展。

实际应用场景：

框架与库设计： 许多成熟的框架和库都大量使用了抽象类。例如，.NET中的
```
Stream
```
类就是一个抽象类，它定义了读写数据的基本操作（
```
Read
```
、
```
Write
```
），但具体的实现则由
```
FileStream
```
、
```
NetworkStream
```
等子类提供。这使得用户可以统一地操作不同来源的数据流。
模板方法模式（Template Method Pattern）： 这是一个经典的设计模式，抽象类在其中扮演着核心角色。它定义了一个算法的骨架，将一些步骤延迟到子类中实现。抽象类中的一个非抽象方法调用了多个抽象方法，由子类填充这些抽象方法的具体逻辑。例如，一个抽象的
```
BuildReport
```
类，其中
```
GenerateHeader()
```
、
```
GenerateBody()
```
、
```
GenerateFooter()
```
是抽象方法，而
```
CreateFullReport()
```
是非抽象方法，它按顺序调用这三个抽象方法。
数据访问层（DAL）设计： 我经常会创建一个抽象的
```
BaseRepository
```
类，它可能包含一些通用的数据库连接管理、事务处理逻辑，同时定义抽象的
```
Add()
```
、
```
GetById()
```
、
```
Update()
```
等方法，让具体的
```
UserRepository
```
、
```
ProductRepository
```
去实现针对特定实体的数据操作。
领域模型中的层级结构： 在复杂的业务领域中，往往存在着概念上的父子关系。比如，一个
```
Employee
```
（员工）可以是抽象的，因为它可能包含
```
FullTimeEmployee
```
（全职员工）和
```
PartTimeEmployee
```
（兼职员工）等具体类型，它们有共同的属性（姓名、ID），但可能有不同的计算工资方式（抽象方法）。
事件处理系统： 抽象的
```
EventHandler
```
类可以定义一个
```
HandleEvent()
```
抽象方法，然后不同的具体事件处理器（如
```
LoginEventHandler
```
、
```
OrderCreatedEventHandler
```
）继承它并实现各自的事件处理逻辑。

总的来说，抽象类是我在设计软件架构时一个非常趁手的工具。它让我能在高层次上定义行为规范，同时又能在低层次上提供具体的实现，从而在灵活性和强制性之间取得一个恰到好处的平衡。

抽象类和接口有什么区别？我该如何选择？

抽象类和接口都是实现多态和面向对象设计的重要工具，但它们的设计哲学和使用场景有着明显的区别。我常常把它们比作两种不同类型的“合同”。

核心区别：

实现能力：
- 抽象类： 可以包含字段、构造函数、有具体实现的方法（非抽象方法），以及抽象方法。这意味着抽象类可以提供一部分默认实现，子类可以直接继承或选择性地重写。
- 接口： 在C# 8之前，接口只能包含方法、属性、事件和索引器的签名，不能有任何实现代码（除了静态成员）。从C# 8开始，接口可以包含默认实现的方法（default Interface Methods），但这主要是为了向后兼容和提供可选的默认行为，其核心仍然是定义“契约”，而非提供完整的实现。接口不能有字段和构造函数。
继承方式：
- 抽象类： C#是单继承语言，一个类只能继承一个基类（无论是抽象类还是普通类）。这是“is-a”（是一个）的关系，比如“猫是一种动物”。
- 接口： 一个类可以实现多个接口。这是“can-do”（能做）的关系，比如“猫能跑，猫能叫”。
访问修饰符：
- 抽象类： 抽象成员可以有
```
public
```
  、
```
protected
```
  等访问修饰符。
- 接口： 接口成员默认就是
```
public
```
  的，不需要（也不能）显式指定访问修饰符。
构造函数与字段：
- 抽象类： 可以有构造函数和实例字段。
- 接口： 不能有实例构造函数和实例字段（尽管C# 8后可以有静态字段）。

我的选择策略：

在实际开发中，选择抽象类还是接口，往往取决于你想要表达的设计意图和具体的需求。

选择抽象类：

当你有一个“is-a”的关系时： 如果你的类之间存在明显的继承关系，并且它们“是”某种东西的特殊类型，那么抽象类通常是更好的选择。例如，
```
Car
```
、
```
Motorcycle
```
“是”
```
Vehicle
```
。
当你需要共享代码实现时： 如果多个派生类会共享一些通用的方法实现、字段或构造函数逻辑，那么将这些共同的部分放在抽象类中可以避免代码重复。抽象类能提供部分实现，让子类在此基础上进行扩展。
当你需要定义非公共成员时： 如果你需要定义
```
protected
```
或
```
private
```
的成员供子类使用或在内部维护状态，那么抽象类是唯一选择。
当你的基类需要维护状态时： 抽象类可以有实例字段，这使得它能够维护一些公共的状态信息。

选择接口：

当你有一个“can-do”或“has-a”的关系时： 如果你关注的是对象的能力或行为，而不是它的类型层级，那么接口是理想选择。例如，
```
Dog
```
和
```
Robot
```
都可以实现
```
IMovable
```
接口。
当你需要实现多重行为时： 由于C#不支持多重继承，但支持多重接口实现，所以当一个类需要同时具备多种不相关的行为时，接口是唯一的解决方案。比如，一个
```
Student
```
对象可能既
```
IComparable
```
（可比较），又
```
IDisposable
```
（可释放资源）。
当你想要完全解耦实现时： 接口只定义契约，不包含实现细节。这使得实现类与接口之间高度解耦，你可以很容易地替换掉某个接口的实现，而不会影响到使用该接口的代码。这对于构建可插拔、可测试的系统至关重要。
当你需要定义插件或扩展点时： 接口非常适合定义插件架构的扩展点，因为它们只规定了功能，不限制实现方式。

我的经验是：

很多时候，抽象类和接口并非互斥，它们可以协同工作。一个抽象类可以实现一个或多个接口，从而既能提供部分共享实现，又能遵守多个行为契约。例如，一个抽象的

BaseRepository

类可以实现

IRepository<T>

接口，这样既能强制所有仓库类实现基本的CRUD操作，又能提供一些通用的方法实现。选择哪一个，更多的是思考“我的设计目的是什么？”和“我希望强制什么，又允许什么灵活？”。

抽象方法和虚方法又有什么不同？什么时候用

override

关键字？

抽象方法和虚方法都是C#中实现多态性的重要机制，它们都允许子类修改或定义基类的行为。然而，它们在定义、目的和强制性上存在显著差异。

抽象方法（Abstract Method）：

定义： 抽象方法只包含方法的签名（名称、参数、返回类型），没有具体的方法体。它以
abstract
关键字声明，并且必须存在于一个抽象类中。
目的： 抽象方法的目的是强制子类提供自己的实现。它代表了一种“未完成”或“待实现”的行为。基类知道有这个行为，但不知道如何具体实现，所以把它留给子类。
强制性： 任何继承了包含抽象方法的抽象类，并且自身不是抽象类的子类，必须使用
override
关键字来实现所有继承的抽象方法。如果子类没有实现所有抽象方法，那么它自己也必须声明为抽象类。
隐式虚方法： 抽象方法是隐式
```
virtual
```
的，你不能同时使用
abstract
和
```
virtual
```
修饰符。

虚方法（Virtual Method）：

定义： 虚方法包含方法的签名和具体的方法体（即有默认实现）。它以
```
virtual
```
关键字声明，可以存在于抽象类或非抽象类中。
目的： 虚方法的目的是提供一个默认的行为，同时允许子类选择性地重写（
override
）这个行为。基类提供了一个通用的实现，但预留了让子类定制的空间。
强制性： 子类不需要重写虚方法。如果子类没有重写，它将直接继承并使用基类的默认实现。
不能在接口中声明： 接口不能直接包含虚方法，但可以包含默认实现方法（C# 8+），这在某种程度上提供了类似的功能，但概念上仍有区别。

什么时候用

override

关键字？

override

关键字是C#中用于实现多态性的关键部分，它明确地告诉编译器：你正在提供一个新实现，以替换或扩展从基类继承的抽象方法或虚方法。

实现抽象方法时： 当你的类继承了一个抽象类，并且这个抽象类中定义了抽象方法时，你必须在你的子类中使用

override

关键字来提供这些抽象方法的具体实现。这是编译器强制的，否则会报错。

public abstract class Printer {     public abstract void PrintDocument(string document); // 抽象方法，无实现 }  public class LaserPrinter : Printer {     public override void PrintDocument(string document) // 必须使用 override 实现     {         Console.WriteLine($"Laser Printer printing: {document}");     } }