将数据公开为C#属性 - 好还是坏?

时间:2011-11-21 07:43:16

标签: c# oop properties

我有点不理解这一点,并且想知道是否有人可以帮助我理解这一点。

所以这就是问题,我有一个没有必要参数的类。如果用户没有设置字段,我可以采用默认值并继续。以前,我设计了与Joshua Bloch的Builder Pattern(Effective Java)(不可变对象)相同的类。我没有任何理由让这个类不可变,除了我不想拥有伸缩构造函数并且我不想暴露类的数据这一事实。

但是现在,一位程序员朋友试图说服我可以使用C#属性从类中公开数据。我不确定这一点,我仍然觉得我不应该让用户捣乱数据。

也许我的理解完全错了。有人可以清楚我对这个问题的疑问,是否从课堂上公开数据是好还是坏?

如果它好,那么在什么情况下好呢?或者,如果有人可以请指出我澄清这一点的文章/书我会非常感激。

谢谢!

5 个答案:

答案 0 :(得分:4)

如果需要或在课堂外感兴趣,请在课堂上公开数据,如果不是,则不要这样做。如果它只需要在外部读取,则将其公开为只读,如果它应该能够被更改,则将其公开为完整的读/写属性。否则,请将其保存在私人领域。

答案 1 :(得分:2)

不可变类更易于推理,特别是在多任务应用程序中,但它们通常在性能上付费(因为当您需要更改字段的值时,您需要使用新值再次构建整个类)。 所以,你可以没事或(取决于你的编码)甚至更好的属性,但像往常一样,没有银弹。

可设置属性也是为某些特定框架或库(例如ORM,如NHibernate)编码对象的唯一方法,因为您无法控制库/框架如何初始化对象。

关于构造函数,C#4有optional parameters,它可以帮助你避免长链构造函数,并且更清楚地传达参数是可选的这一事实。

但是我不能想到很多情况下你会得到一个带有很长可选参数列表的类。如果你发现你经常编写这样的类(特别是使用构建器模式,这在类的消费者方面非常优雅,但是使类本身的代码复杂化),你可能使用了错误的设计。你确定你没有要求你的课程承担太多责任吗?

答案 2 :(得分:0)

它主要取决于应用程序上下文中Class的用途(你能给我们提供更多细节吗?)。 无论如何,通过声明将setter设置为private,可以使属性免受外部更改: http://msdn.microsoft.com/en-us/library/bb384054.aspx

public string UserName { get; private set; }

答案 3 :(得分:0)

当班级的消费者需要数据时,这是“好的”。您有两种提供物业的可能性。 如果您只想提供信息用途,请选择这样的只读属性:

public string MyInformation { get; private set; }

如果您需要允许消费者更改该属性,请将setter公之于众:

public string MyChangeableInformation { get; set; }

但如果消费者不需要获取信息,那么将其隐藏在您的班级中!

答案 4 :(得分:0)

  

但现在,一位程序员朋友正试图说服我这样做   好的,可以使用C#属性公开类中的数据。我不是   确定这一点,我仍然觉得我不应该允许用户   捣乱数据。

根据经验,方法应表示操作,而属性表示数据。您的朋友可能试图告诉您的是,您可以将班级数据公开给外界,并且仍然可以完全控制其他班级如何访问数据。在您的情况下,正如其他人所提到的,您可以使用具有私有设置器的属性,这样调用者就不应该能够修改数据。