扩展接口模式

在 .Net 3.5 中的新扩展允许从接口中分离功能。

比如，在 .Net 2.0 中：

public interface IHaveChildren {
    string ParentType { get; }
    int ParentId { get; }

    List<IChild> GetChildren()
}

可以（在3.5中）变成：

public interface IHaveChildren {
    string ParentType { get; }
    int ParentId { get; }
}

public static class HaveChildrenExtension {
    public static List<IChild> GetChildren( this IHaveChildren ) {
        //logic to get children by parent type and id
        //shared for all classes implementing IHaveChildren 
    }
}

这个机制对于许多接口来说似乎是更好的。它们不再需要抽象基类来共享这段代码，从功能上来看代码仍然有效。这可以使代码更易于维护和测试。
唯一的缺点是抽象基类的实现可能是虚拟的，但这能否得到解决（一个实例方法是否会隐藏具有相同名称的扩展方法？这样做是否会使代码混乱？）
还有其他原因不经常使用这种模式吗？
澄清：
是的，我看到使用扩展方法的趋势是到处都有它们。如果没有进行大量同行评审，我会特别小心在.Net值类型上使用任何一个（我认为我们仅在字符串上有一个.SplitToDictionary() - 类似于.Split()，但也带有键值分隔符）
我认为这里有整个最佳实践的辩论;-)
（顺便说一句：DannySmurf，你的私人消息听起来很可怕。）
我在这里特别询问了先前我们使用接口方法的扩展方法的使用。
我试图避免大量级别的抽象基类 - 实现这些模型的类大多已经有了基类。我认为这个模型可能比添加其他对象层次结构更易于维护和不过度耦合。
这是 MS 对 Linq 的 IEnumerable 和 IQueryable 所做的吗？