【问题标题】:Use of extension methods to enhance readability使用扩展方法来增强可读性
【发布时间】:2009-07-08 10:26:02
【问题描述】:

对于使用除了提高可读性之外没有其他目的的扩展方法的一般想法是什么?

如果不使用扩展方法,我们可能有方法

IEnumerable<DependencyObject> GetDescendents(DependencyObject root) {}

可以调用

var descendents = GetDescendents(someControl);

foreach (var descendent in GetDescendents(someControl)) {}

虽然这没有什么问题,但我发现 instance.method() 表示法更具可读性,因此我可能会考虑使用此签名将其作为扩展方法

public IEnumerable<DependencyObject> GetDescendents(this DependencyObject root) {}

允许它被调用

var descendents = someControl.GetDescendents();

foreach (var descendent in someControl.GetDescendents()) {}

所以我的问题是你认为这是合理的还是滥用扩展方法。如果只是以不同的方式声明功能,我会毫不犹豫;但是使用扩展方法需要将其编码在不同的静态类中,这一事实让我想知道是否值得付出努力。我在上面使用的示例是一个相当通用的示例,并且可能具有将在多个地方使用的扩展方法的优点,但通常情况并非如此,我将在同一文件中编码包含扩展的静态类使用它的单个类。

【问题讨论】:

    标签: c# coding-style extension-methods


    【解决方案1】:

    我认为扩展方法的一大优势是可发现性。如果有人不知道他们的团队成员之一在某处的实用程序类中创建了 GetDescendents 方法,他们将永远不会使用它。但是,如果该方法开始出现在 Intellisense 或对象浏览器中,他们很有可能会偶然发现它。如果您开始更广泛地使用扩展方法,人们将开始使用我提到的工具来寻找增加价值的扩展。

    【讨论】:

    • 我从来没有想过这个方面。这很有意义。
    【解决方案2】:

    大多数(如果不是全部)扩展方法在某种程度上都属于这一类,因为它们不能对类的内部进行操作,而不是静态函数。无论如何,任何扩展方法都可以用一个代表对象的额外参数在静态类中重写(可以说,这正是扩展方法的本质)。

    对我来说,这完全是一个风格问题:在您提供的示例中,我可能会选择扩展方法。我认为这里的重要问题是,如果我要重新实现这个类,这个函数是我作为类的一部分编写的吗?这样有意义吗?如果是,那就去吧它,如果不是,那么考虑一个不同的解决方案。

    【讨论】:

      【解决方案3】:

      扩展方法的存在只是为了提高可读性 - 它只是一种语法快捷方式,允许您通过在第一个参数上指定 this 关键字来调用相关对象实例上的方法。所以我认为这是完全合理的。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 1970-01-01
        • 2023-04-03
        • 2016-06-21
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        相关资源
        最近更新 更多