将数据暴露为c#属性——好还是坏

本文关键字：属性 数据 暴露 | 更新日期: 2023-09-27 18:15:20

我有点不明白这一点，想知道是否有人能帮助我理解这一点。

问题来了，我有一个类，其中没有必要的参数。如果用户没有设置字段，我可以采用默认值并继续。以前，我设计了与Joshua Bloch的Builder Pattern (Effective Java)相同的类(不可变对象)。我没有任何好的理由使类不可变，除了我不想有可伸缩的构造函数和我不想暴露类的数据。

但是现在，一个程序员朋友试图说服我，使用c#属性从类中公开数据是可以的。我不确定这一点，我仍然觉得我不应该允许用户乱动数据。

也许我的理解完全错了。有人能澄清我的疑问吗，公开类中的数据是好是坏?

如果它是好的，那么在什么情况下它是好的?或者，如果有人能给我指出澄清这一点的文章/书，我将非常感激。

谢谢!

将数据暴露为c#属性——好还是坏

如果需要或类外感兴趣，则在类中公开数据，如果不需要则不这样做。如果只需要在外部读取，则将其公开为只读;如果应该能够更改，则将其公开为完整的读/写属性。否则，将其保存在私有字段中。

不可变类更容易理解，特别是在多任务应用程序中，但它们通常会影响性能(因为当您需要更改字段的值时，您需要使用新值重新构建整个类)。因此，您可以使用属性，或者(取决于您正在编写的代码)甚至更好，但通常没有银弹。

可设置属性也是为某些特定框架或库(例如像NHibernate这样的orm)编写对象的唯一方法，因为你无法控制库/框架如何初始化对象。

关于构造函数，c# 4有可选参数，这可以帮助你避免构造函数的长链，也可以更清楚地传达参数是可选的事实。

然而，我想不出很多情况下，你最终会得到一个长列表的可选参数的类。如果您发现经常这样编写类(特别是使用构建器模式，它在类的消费者端看起来非常优雅，但使类本身的代码变得复杂)，那么您可能使用了错误的设计。你确定你没有要求你的班级承担太多的责任吗?

这基本上取决于你的类在应用程序上下文中的目的是什么(你能给我们更多的细节吗?)无论如何，你可以通过声明setter为private来使属性免受外部更改:http://msdn.microsoft.com/en-us/library/bb384054.aspx 

public string UserName { get; private set; }

当类的消费者需要这些数据时，这是"好的"。您有两种提供属性的可能性。如果您只想提供用于信息目的的属性，那么选择一个只读属性，如下所示:

public string MyInformation { get; private set; }

如果需要允许消费者修改该属性，那么就像这样将setter设置为public: 

public string MyChangeableInformation { get; set; }

但是如果消费者不需要获取信息，那么将其隐藏在类中!

但是现在，一个程序员朋友试图让我相信它是可以使用c#属性从类中公开数据。我不是我确信这一点，但我仍然觉得我不应该允许用户这样做与数据混淆。

根据经验，方法应该表示操作，而属性应该表示数据。您的朋友可能试图告诉您的是，您可以将类的数据公开给外部世界，同时仍然可以完全控制其他类如何访问这些数据。在您的情况下，正如其他人提到的，您可以将属性与私有setter一起使用，这样调用者就不应该能够修改数据。

相关文章：