使用扩展:权衡利弊与利弊

最近我问了一个关于如何清理我认为丑陋代码的问题.一个建议是创建一个扩展方法,它将执行所需的功能并返回我想要的功能.我的第一个想法是'太棒了!Extensions有多酷......"但经过一番思考后,我开始对使用Extensions有了第二个想法......

我主要担心的是,Extensions似乎是一种自定义的"快捷方式",可以让其他开发人员难以遵循.我理解使用扩展可以帮助使代码语法更容易阅读,但是如何跟随幕后的声音呢？

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

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()

所以我做了一些挖掘,发现了一些关于使用Extensions的优点/缺点的文章.对于那些倾向于看看以下链接的人:

MSDN:扩展方法

推广方法最佳实践

扩展方法

我无法确定哪种方式更好.自定义扩展执行我想要他们做的事情或更多显示的代码来完成相同的任务？我真的很想学习"真正的"开发人员对这个主题的看法......

就个人而言,我认为扩展方法可读性的"问题"被夸大了.如果你专注于使您的代码容易的方面看是什么它在做什么,这是不是更重要的大部分时间是如何它这样做.如果开发人员想要追踪并了解幕后实际发生的事情,他们总是可以点击执行.

扩展方法的主要问题是它们的发现方法 - 即通过指定的命名空间而不是指定的类.虽然这是另一回事:)

我并不是建议你随意添加扩展方法,但是我会认真考虑你需要知道方法中每个表达式的工作方式,而不是通过它来查看它在广义上的作用.

编辑:您对术语的使用可能会误导您.没有"扩展对象"这样的东西 - 只有"扩展方法",它们必须存在于静态类型中.所以你可能需要引入一个新类型,但你不会再创建任何对象.

[OP]定义一个方便的方法,但它真的值得另一个类对象的开销吗？

在此方案中不会创建额外的类对象.在引擎盖下,扩展方法与静态方法没有区别.扩展方法容器有一个额外的元数据条目,但这是非常小的.

[OP]如果有人想重用我的代码片段而不理解扩展对象,会发生什么？

那么这将是教育他们的好时机:).是的,新开发人员可能不习惯使用扩展方法启动.但这不是一个孤立的特征.它在我在内部和网络上看到的所有代码示例中的使用越来越多.对于开发人员来说,这是绝对值得学习的东西.我不认为它符合"让人们知道更深奥"的范畴