【问题讨论】：
标签： c#
由于属性只是方法的语法糖，我不明白为什么 C# 应该有没有扩展属性的扩展方法。
【讨论】：
这是关于数据绑定的，假设我有一个要绑定到我的 UI 的对象，我想根据对象的其他属性隐藏它。我可以为 IsVisible 或 Visibility 添加扩展属性并将该属性绑定到 UI。
您无法绑定扩展方法，但能够将数据绑定属性添加到您无法扩展的现有类型可能非常有用。
【讨论】：
在我的书中，扩展属性的#1 最重要的原因是围绕无主代码实现流畅的接口模式。我围绕 NHibernate 会话构建了一个包装器，使其使用起来更加直观，因此我可以执行类似于
的逻辑public bool IsInTransaction
{
get { return _session.Is().Not.Null && _session.Is().InTransaction; }
}
Is 必须是一个方法看起来很愚蠢，因为除非我直接修改会话对象上的源，否则我无法将 Is 作为属性插入。
【讨论】：
我不知道为什么不。属性只是具有不同语法的 getter/setter 方法。
【讨论】：
我不认为扩展属性几乎同样有用。我发现自己主要使用属性来封装字段（经典的 get; set;）或提供只读优点（只是对私有、只读、constructor-set 字段的获取）。由于扩展不能访问私有成员，我真的不明白这一点，特别是对于“set;”。做任何事情，“设置；”无论如何都只需要调用其他方法。然后你会遇到属性抛出异常的问题。
由于扩展仅限于使用公共属性和方法，我发现使用实用程序类的代码更简洁、更容易阅读。归根结底，我们正在使用扩展方法使 LINQ 看起来更漂亮。为了防止开发人员做错事，我可以在我的 LINQ 中到处处理一个额外的 () 并坚持使用扩展方法。
【讨论】：
我想这会很棒，只要在使用它们时没有性能损失或性能损失最小。
【讨论】：
似乎它很容易被滥用。正如其他人所提到的，C# 属性只是方法的语法糖。但是，将它们实现为属性具有一定的含义：访问不会有副作用，并且修改属性应该非常便宜。后一点至关重要，因为扩展属性似乎总是比传统属性更昂贵。
【讨论】：
拥有它会是一件好事，但我看到很多人说他们想要它用于数据绑定，这是不可能的，因为它使用反射。
【讨论】：
肯定会添加到我们可以使用的工具库中。
现在就我的意见而言，是的，他们应该这样做，但就像任何事情一样，开发人员需要在需要时正确使用它。像大多数新功能一样，许多开发人员在没有完全理解它们以及何时/如何/在哪里/如何最好地使用它们的情况下使用它们。我知道我有时也会沉迷其中。
但是，当然，请继续。我可以看到自己在某些场景中使用它
【讨论】：
我猜索引属性将只是我们将在 4.0 中看到的一大袋显着增强功能中的一个库存填充物。
【讨论】：
开发人员应使用属性来组织名称的层次结构，并避免使用驼峰式或下划线连接名称。 例如，他们应该扩展字符串类而不是 HttpUtility.UrlDecode 以使用类似“some str”.decode.url 目前在 C# 中这样做的唯一方法是：“some str”.decode().url
【讨论】：
是的，请。
还添加索引属性和静态扩展内容，因为我非常希望 System.Console 使用它（这不是开玩笑！）。
【讨论】：
不，属性只是隐藏为代码真正生成的内容的一种方式。如果您查看反映的代码或 IL，您可以确定您真正得到的结果如下：
public string MyProperty { get; set; }
变成
public string get_MyProperty(){ return <some generated variable>; }
public string set_MyProperty(string value) { <some generated variable> = value; }
只有两种方法。
【讨论】：