抽象类继承接口的用法缘由

用接口的同时，又用抽象类，这是很常见的一种设计方式

这样可以在提供一定重用代码的基础上，也为user扩展提供了切入点。

举个例子，ASP.Net里的IHttpHandler接口和Page类。

Page是abstract class，其实现了接口IHttpHandler。在Page基类里微软实现了一个页面生命周期的模板，这样一般的用户你可以直接从Page基类里继承，只要去Override一些局部的点就可以了，比如OnLoad方法，不用每个用户自己再去写一遍整个页面生命周期的代码。这里做到了代码的重用，也就是模板流程的重用。其实就是GOF里的模板方法模式典型例子。

在从Page基类派生，也可以通过在子类Override来达到扩展，但是这个扩展会被限制在Page的页面生命周期模型的范围内。
假设，有些用户可能此时会有特殊要求，微软实现的页面生命周期无法达到用户的要求，那么此时，你可以从IHttpHandler接口来继承实现你自己的功能，这样你可以完全抛弃掉Page基类里的那套页面生命周期模型，实现你自己的特殊需求。

而对于APS.Net的Runtime框架，它看到的永远都只是IHttpHandler接口的引用，而不关心引用所指向的具体对象是从Page继承的子类还是你自己写的非Page的子类。这可以看成是GOF的策略模式的典型例子。

所以大部分的框架设计都会看到 策略模式 + 模板方法模式的结合运用，也就是在使用接口的同时，又使用抽象类，在抽象基类里就是你为user提供的一个（建议的）默认的接口实现的半成品，用户可以选择在你的半成品基础上做少量扩展形成成品，也可以完全从接口实现自己的成品而不通过你的半成品。