抽象类不能实例化，用于定义必须由子类实现的抽象成员，同时可包含具体实现，强制契约并共享代码，适用于“is-a”关系和需部分实现的场景。
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接口，这样既能强制所有仓库类实现基本的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}"); } } 重写虚方法时： 当你的类继承了一个包含虚方法的基类时，如果你想改变基类提供的默认行为，那么你必须使用
override
关键字来提供你自己的实现。如果你不使用
