悠悠楠杉
网站页面
.NET中接口（Interface）和抽象类（AbstractClass）的区别
11/16
在.NET开发实践中，接口（Interface）与抽象类（Abstract Class）是实现多态性和代码复用的重要工具。尽管它们都能定义方法契约并被子类实现或继承，但二者在设计理念、语法限制和应用场景上存在本质差异。理解这些差异，是写出高内聚、低耦合代码的关键。
首先从语法层面来看，接口是一种纯粹的契约声明。在C#中，接口使用interface关键字定义，其中的方法默认为公共且无实现（C# 8.0后支持默认实现，但仍有限制），不能包含字段（除非是常量），也不能有构造函数。它只规定“能做什么”，而不关心“怎么做”。例如：
csharp
public interface ILogger
{
void Log(string message);
void Error(string error);
}
而抽象类使用abstract class定义，它可以包含抽象方法（无实现）、具体方法（有实现）、字段、属性、事件甚至构造函数。抽象类更像一个“不完整的类”，允许部分实现，留给子类去完成剩余逻辑。例如：
csharp
public abstract class Animal
{
protected string Name;
public Animal(string name)
{
Name = name;
}
public abstract void MakeSound(); // 子类必须实现
public void Sleep()
{
Console.WriteLine($"{Name} is sleeping.");
}
}
从继承机制上看，C#不支持多重类继承，因此一个类只能继承一个抽象类。但一个类可以实现多个接口，这使得接口在需要组合多种行为时更具灵活性。比如一个服务类既需要日志功能，又需要缓存能力，可以通过实现ILogger和ICacheProvider两个接口来达成。
更重要的是设计意图的不同。接口强调“角色”或“能力”。比如IDisposable表示一个对象具有释放资源的能力，IEnumerable<T>表示可被枚举。它关注的是对象对外表现出的行为特征，而不是其本质是什么。而抽象类更适合表达“是什么”的关系。例如FileStream和MemoryStream都是Stream的子类，它们共享大量基础读写逻辑，抽象类提供了共性实现，体现了“is-a”关系。
在版本演进方面，接口的变更风险更高。一旦发布了一个接口，添加新方法将导致所有实现类编译失败（除非使用默认接口方法）。而抽象类可以在不影响已有子类的前提下，安全地添加非抽象方法。这也意味着抽象类更适合构建框架的核心基类，便于后续扩展。
性能上，两者几乎没有差别。接口调用通过虚方法表（vtable）实现，与抽象类的抽象方法调用机制一致。现代JIT编译器对两者都有良好优化，不应因性能顾虑而牺牲设计合理性。
实际开发中，建议优先使用接口，尤其是在定义服务契约、插件体系或跨模块通信时。当多个类有共同的状态和行为，并且需要共享代码实现时，才考虑使用抽象类。微软官方框架如ASP.NET Core大量使用接口（如IController, IMiddleware），正是为了提升可测试性和可替换性。
总之，接口与抽象类不是非此即彼的选择，而是互补的设计工具。掌握它们的本质差异，才能在复杂系统中构建出清晰、灵活、易于维护的架构。
