多重继承感觉并没必要，这对于减少代码的混乱有很大帮助，我想微软也是出于这方面的考虑才不在C#中实现多重继承的吧。

所以，再用变相的方法实现多重继承，我觉得更没必要。

如果确实有必要，是不是可以通过某些设计模式来解决呢？

@Cat Chen
在接口上提供默认实现一般情况下并不需要，不应该滥用，但是这种方式在某些情况下是有价值的。
微软自己也有这样的例子，System.Linq中的IQueryable<T>就是一例，它自己没有声明任何方法，但是在Queryable类中为IQueryable<T>提供了大量的扩展方法。我自己也感觉以前的框架中某些接口是可以使用一些扩展方法的。
使用这样的方法，需要对接口的设计有比较全面的考虑。

我们在系统设计时经常会抽象出一些接口，并为接口提供一个抽象类作为默认的实现，然后实际使用的类可以从抽象类派生。

很大程度上是减低二次扩展的复杂性，接口是一个纯约束对外的规则，并不存在任何的实现。实现抽象类作为默认可以提供后期扩展内部需要的很多功能。

楼主的思路绝对创新

不知所云，还C# 3.0,C#1.0就可以做到，典型的标题党

同意楼上。

还是伪 多集成；
添加的这个东西和

public static void TestB(this ITestB obj)
和
public static void TestB(ITestB obj)

原则上没啥两样、就是用着舒服了一点
用多了看代码时候迷糊，尤其是看别人的代码的时候
就和js似的、别人动态在那个对象上加了个东西有时候找半天

不过在VS里基本没这问题；有图标可以看见

@在路上的牛
你自己已经说出了，为什么不应该在接口上做默认实现。Framework Design Guideline说明了，建议的做法正式抽象的DbCommand实现IDbCommand，再派生出子类。不应该尝试直接在IDbCommand上面添加默认实现。

说实话，还真没用到过多继承，不过楼主给出了一个思路，Thanks。

这个方法是有很多局限。而且扩展方法是容易把人搞混，当初看Linq的代码，一个接口的实现方法半天没找到，后来才想起可能会在某个静态类的扩展方法中。。。

呵呵,但是脱离OO的继承,已经很大程度失去了原有的意义嘛.

目前对扩展方法持谨慎态度,怕会导致一些不必要的混乱..

调用类的方法时编译器先从类中找，找不到再找扩展方法，再找不到就编译错误。

@Dflying Chen
因为很多时候，对接口的方法我们是可以提供一个默认的实现的，如果不提供这样一个抽象类，那每个实现接口的类都要写上许多一样的方法实现，是个不好的设计。System.Data下的许多类都是按照接口 - 抽象类 - 具体类的方式设计的，比如IDbCommand - DbCommand - SqlCommond/ODBCCommand/OLECommand
再比如在ORM框架中，我们可以为所有的DataObject设计1个Interface，里面可能有基本的DataState, AccpetChange(),Original...，接下来也会提供一个抽象类来实现这些方法，实际的业务对象从此抽象类派生，而不是每个业务对象都为这些功能写一套一样的实现代码。

我们在系统设计时经常会抽象出一些接口，并为接口提供一个抽象类作为默认的实现，然后实际使用的类可以从抽象类派生。
----------
为什么要这样做呢？能详细说明一下么？