c# - 扩展接口(interface)模式

Question

.Net 3.5 中的新扩展允许将功能从接口(interface)中分离出来。

例如在 .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 
    }
}

在我看来，这对于许多接口(interface)来说是一种更好的机制。他们不再需要抽象基础来共享此代码，并且代码在功能上是一样的。这可以使代码更易于维护和测试。

唯一的缺点是抽象基础实现可以是虚拟的，但是可以变通吗(实例方法会隐藏同名的扩展方法吗？这样做会混淆代码吗？)

还有其他不经常使用此模式的原因吗？

---

澄清:

是的，我看到扩展方法的趋势是无处不在。我会特别小心在没有大量同行评审的情况下使用任何 .Net 值类型(我认为我们在字符串上唯一的一个是 .SplitToDictionary() - 类似于 .Split() 但也采用键值分隔符)

我认为那里存在完整的最佳实践辩论 ;-)

(顺便说一句:DannySmurf，你的 PM 听起来很吓人。)

我在这里特别询问有关在我们以前有接口(interface)方法的地方使用扩展方法的问题。

---

我试图避免很多层次的抽象基类——实现这些模型的类大多已经有基类。我认为与添加更多对象层次结构相比，此模型更易于维护且过度耦合更少。

这是 MS 对 Linq 的 IEnumerable 和 IQueryable 所做的吗？

Answer 1

扩展方法应该只是这样使用:扩展。任何关键结构/设计相关的代码或重要的操作都应该放在一个对象中，该对象由类或接口(interface)组成/继承自类或接口(interface)。

一旦另一个对象尝试使用扩展的对象，它们将看不到扩展并且可能不得不再次重新实现/重新引用它们。

传统观点认为扩展方法只能用于:

• 实用类，如 Vaibhav 所述
• 扩展密封的第 3 方 API