C# 3.0 什么时候使用扩展方法是一种好的实践？

扩展方法的功能确实很有趣，但我觉得在类之外创建“类成员”的想法不是100%可以接受的

我希望尽可能避免这种做法，但有时使用扩展方法看起来更好

---

您认为哪些情况是使用此功能的最佳实践？

我认为扩展方法的最佳位置是“助手”方法或“快捷方式”，它们通过为现有方法的参数提供默认值或隐藏重复的方法调用链，使现有API更容易和更干净

---

与通常认为可以“扩展”没有源代码访问权限的类相反，您不能。您无法访问私有方法和对象，您所能做的就是润色公共API并使其符合您的喜好（不推荐）。

当类不可扩展且您无法控制源代码时。或者，如果它是可扩展的，但您更希望能够使用现有类型而不是您自己的类型。只有当扩展不改变类的特征，而只是提供（IMO）缺少的功能时，我才会执行后一种操作。

扩展方法是一种很好的方法，可以将功能添加到您不拥有（无源）、位于框架中或出于任何原因不想继承的类中

---

我喜欢，但你是对的。应该明智地使用它们。

它们非常适合于接口（您可以添加仅使用接口上现有方法的“复合”行为）-LINQ to Objects就是这方面的主要示例

它们还可用于创建流畅的接口，而不会影响正在使用的类型。我最喜欢的示例可能不适用于生产代码，但适用于单元测试：

DateTime birthday = 19.June(1976) + 8.Hours();

---

基本上，如果您不想或不能向类型本身添加行为，但希望使类型更易于使用，那么扩展方法值得考虑。如果您发现自己编写了一组与特定类型相关的静态方法，请考虑扩展方法是否不会使对这些方法的调用看起来更好。

在我看来，扩展方法有助于增强代码的可读性和可维护性。在您无法访问原始类或方法违反原始类的“单一责任原则”的实体上，它们似乎是最好的。后者的一个例子是DSL。DSL模型通过扩展方法进行扩展，扩展方法用于简化T4模板制作，但除非方法与模型具体相关，否则不会向模型中添加任何方法。

它们的理想用途是当您有一个将在许多地方实现的接口时，因此您不想给实现者带来巨大负担，但是，您也希望从调用方的角度来看，该接口能够方便地使用

因此，您将“helpers”放在一组扩展方法中，使接口本身保持良好和精简

interface IZoomable
{
    double ZoomLevel { get; set; }
}

public static void SetDefaultZoom(this IZoomable z)
{
    z.ZoomLevel = 100;
}