什么时候使用扩展方法是一种好习惯？ [复制]答案

【问题标题】：When the use of an extension method is a good practice? [duplicate]什么时候使用扩展方法是一种好习惯？ [复制]
【发布时间】：2009-03-24 21:23:34
【问题描述】：

扩展方法确实很有趣，但我对在类之外创建“类成员”的想法并不 100% 满意。

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

您认为在哪些情况下可以使用此功能？

【问题讨论】：

【解决方案1】：

我认为扩展方法的最佳位置是“辅助”方法或“快捷方式”，它们通过为现有方法的参数提供默认值或隐藏重复的方法调用链，使现有 API 更简单、更简洁。

与您可以“扩展”您无权访问其源代码的类的普遍看法相反，您不能。您无法访问私有方法和对象，您所能做的就是完善公共 API 并根据自己的喜好进行调整（不推荐）。

【讨论】：

【解决方案2】：

它们非常适合接口（您可以在其中添加仅使用接口上现有方法的“复合”行为）- LINQ to Objects 就是最好的例子。

它们对于创建流畅的界面也很有用，而不会影响正在使用的类型。我最喜欢的示例可能不适合生产代码，但对单元测试很方便：

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

基本上任何你不想或不能为类型本身添加行为，但你想让类型更容易使用的地方，扩展方法都值得考虑。如果您发现自己编写了一堆静态方法来处理特定类型，请考虑扩展方法是否不会使对这些方法的调用看起来更好。

【讨论】：

【解决方案3】：

当类不可扩展并且您无法控制源代码时。或者，如果它是可扩展的，但您更喜欢能够使用现有类型而不是您自己的类型。如果扩展不改变类的字符，而只是提供（IMO）缺少的功能，我只会做后者。

【讨论】：

【解决方案4】：

在我看来，扩展方法有助于增强代码的可读性和可维护性。它们似乎最适合您无法访问原始类或该方法破坏原始类的“单一责任原则”的实体。我们在这里看到的后者的一个例子是 DSL。 DSL 模型使用扩展方法进行扩展，用于使 T4 模板更容易，但除非它们与模型特别相关，否则不会向模型添加任何方法。

【讨论】：

【解决方案5】：

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

因此，您将“帮助程序”放入一组扩展方法中，使界面本身美观而简洁。

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

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

【讨论】：

【解决方案6】：

扩展方法是向您不拥有（无源）、在框架中或出于任何原因不想继承的类添加功能的好方法。

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

【讨论】：