Asp.net core 为什么HttpContext是抽象类而不是接口？

为什么是抽象类而不是接口

类是公共抽象的，所有方法都是公共抽象的。我不明白为什么这个类是抽象类

---

是什么原因导致它是一个抽象类而不是一个接口？

关于这个话题有很多观点（例如）。即使ASP.NET团队通常使用接口，我也能想到一些他们在本例中选择抽象类的原因：

版本控制
我不希望HttpContext类有太大的变化，但是抽象类的版本比接口容易（它们实际上根本没有版本），因为它们可以部分地使用

virtual

关键字实现

封装
抽象类封装了一组功能，其中接口为特定功能提供了更多的契约。类只能实现一个抽象类，这对于

HttpContext

实现是有意义的，例如

向后兼容性
尽管ASP.NET核心是ASP.NET的完全重写，但多年来开发人员一直习惯于使用

HttpContext

类进行编程。这两个类都有很多共同的特点

---

---

请记住，我只是在猜测，也许ASP.NET团队中的一些人可以给我们一些启示。

这是我从Microsoft的Daniel Roth那里得到的回答，他与ASP.NET Core合作

我相信在这种情况下，使用抽象类可以在将来的版本中添加成员，这是接口所不能做到的

---

如果没有一个规范的来源，这些设计问题很难回答，因此这在很大程度上是一种观点，除非ASP.NET团队中有人能够进来回答。也就是说，我怀疑这是因为在不破坏开发人员接口契约的情况下，无法向接口添加成员（向接口添加新成员，所有内容都停止编译）。使用抽象类，可以添加可选择性实现的

虚拟
成员。ASP.NET团队已经在多个地方采用了这种模式。通常抽象基类包含一些子类实现可以利用的默认（即实用工具）或部分实现，而有了接口，就没有地方“挂起”这些东西了。这样，更容易“加速”定制实现。即使所有的方法都是虚拟的，发生这种情况的大门仍然敞开着，因此它可以为子类建立部分/辅助实现的“层”。@escape llc确实如此。但在这种情况下，情况并非如此。这正是我想知道的…看我修改后的评论，仍然适用。