c# - 使用扩展 : Weighing The Pros vs Cons

Question

最近我asked a question关于如何清理我认为丑陋的代码。一个建议是创建一个扩展方法来执行所需的功能并返回我想要的。我的第一个想法是‘太棒了!扩展有多酷......'但经过多思考，我开始重新考虑使用扩展......

我主要担心的是，扩展似乎是一个自定义的“快捷方式”，可能会使其他开发人员难以遵循。我知道使用扩展可以帮助使代码语法更易于阅读，但是跟随幕后的声音呢？

以我之前的问题代码片段为例:

if (entry.Properties["something"].Value != null)
  attribs.something = entry.Properties["something"].Value.ToString();

现在用扩展替换它:

public static class ObjectExtensions
{
    public static string NullSafeToString(this object obj)
    {
        return obj != null ? obj.ToString() : String.Empty;
    }
}

并使用以下语法调用:

attribs.something = entry.Properties["something"].Value.NullSafeToString();

确实是一个方便的方法，但它真的值得另一个类对象的开销吗？如果有人想重用我的代码片段但不了解扩展，会发生什么？我可以很容易地使用具有相同结果的语法:

attribs.something = (entry.Properties["something"].Value ?? string.Empty).ToString()

所以我做了一些挖掘，发现了几篇讨论使用扩展的利弊的文章。对于那些有兴趣的人，请查看以下链接:

MSDN: Extension Methods

Extension Methods Best Practice

Extension Methods

我真的无法决定哪种方式更好。做我想让他们做的事情的自定义扩展或更多显示的代码来完成相同的任务？我真的很想了解“真正的”开发人员对这个话题的看法......

Answer 1

我个人认为扩展方法可读性的“问题”被夸大了。如果你专注于让你的代码在做什么方面易于阅读，那么在大多数情况下，这比它是如何做的更重要。如果开发人员想要追溯并找出幕后实际发生的事情，他们可以随时点击查看实现。

我对扩展方法的主要问题是它们的发现方法 - 即通过指定的命名空间而不是指定的类。不过那是另一回事了:)

我并不是建议您随意放入扩展方法，但我会认真考虑您需要了解方法中每个表达式如何工作的频率，而不是浏览它以了解它在更广泛的术语中的作用。

编辑:您对术语的使用可能会稍微误导您。没有“扩展对象”这样的东西——只有“扩展方法”，它们必须存在于静态类型中。因此，您可能需要引入一种新类型，但不会创建更多对象。