我知道如何使用属性来公开字段,有什么好处等等。我想要了解的(我已经搜索了很多)是:
每个字段是否都需要始终具有包装属性,即使它不需要公开并且仅在内部逻辑中使用?
我认为答案是肯定的,因为即使在某些内部逻辑中对其进行了修改,新值仍然需要进行验证。
如果答案是肯定的,这就是为什么一个房产如此普遍的公共获取和私人设置?
编辑:谢谢你给我的所有答案,但大多数答案与我的问题无关,你们大多数人都在谈论大而复杂的课程,我的简单问题是,我是否应该有一个包装属性对于仅在其类中使用且不需要公开的字段。
编辑2:一些答案表明某些事情可以被接受为无答案,这表明如果不需要逻辑,就不应该使用属性
编辑3:谢谢大家,我重读了大部分评论,并且开始有意义,就像总是一样:)
答案 0 :(得分:2)
这不是其中一个问题,你可以做出很多错误。
那就是说,不,不要把它变成属性,除非你需要在setter或getter中加入一些逻辑,你可能不需要。不要添加不起作用的代码。
"字段不好"不是一个目的。事实上,这是胡说八道。字段存在是有原因的。
如果课程如此庞大,以至于没有人可以跟踪这一切,你需要隐藏彼此之间的部分,它太大而且做得太多了。将其重构为两个或更多可管理的类。
很多时候,随着一个大班级的成长(大多数情况下,自然会有一个非常紧张的焦点,比如一个主要的视角模型,或者在过去不好的日子里的窗口或窗体),我们发现自己写得很少"子系统"在类中有一个或两个具有逻辑的集合和/或获取块。这是一个重构成一个单独的小班级的候选人,这个小班级有一个干净的界面,一个容易重复使用的逻辑和状态的球,它的内部与你的大班级内部混合在一起。给大班级一个小助手类的私人副本。拖放代码就是一个让人想起的例子。
这是一个经典的进展:
#region
放在那个乱七八糟的地方,这样我就不用看了。如果您达到第7阶段,那么过去的时间是干预。
私有财产只是随着时间的推移可能变成有害代码气味的第一个小小的味道。它们不是邪恶的,但它们可能表明您的代码显示出在错误的轴上生长的趋势。
内部与外部验证
很多时候,一个班级需要能够打破自己的规则,并且干净利落地做到这一点。例如,一个属性/字段的验证通常取决于其他属性的值(日期范围等)。你的classe的内部应该能够以任意顺序设置它们而没有任何有趣的业务(有时你会看到" _disableValidation"标志来解决这个问题 - 代码味道)。在课堂上,验证应该是自愿的,并且课程应该保持足够简单,这不是一个问题。类需要允许自己暂时将其置于无效状态,同时禁止或控制任何外部代码将其置于无效状态的方式。也许如果外部代码将其置于无效状态,这是代码允许的,但它会驱动妨碍用户的UI。您不希望拥有奇怪的标志,以允许您的构造函数完成其工作而不会弹出消息框或其他内容。
有时,一个班级需要在自己家中的私密环境中运行nekkid。验证应该是来自类外部代码的输入。
答案 1 :(得分:1)
没有必要这样做,但是通过使用属性而不是字段,您可以更灵活,因为您可以预处理获取和设置变量。将字段更改为已在其他代码中使用的属性可能是一个重大变化。因此,如果您不知道该选择什么,请选择一个属性,以便安全且最灵活。
答案 2 :(得分:-1)
如果您不使用财产 - 请勿创建它 如果您需要更改字段,那么如何创建/更新逻辑如何或更改它将能够在没有属性的情况下完成。
因为您没有公开它 - 您不必担心会破坏其他代码。
如果你有一些"复杂的"实例化/更新该字段的逻辑 - 为它创建一个私有方法。
放一些"额外"在setter中的逻辑甚至值得添加一些"副作用"在getter上 - 可能导致一些奇怪的行为或错误,因为当我初始化类
时var order = new Order
{
Id = 1001,
Reference = "Reference one",
CustomerId = 2001
}
我不希望分配CustomerId
会导致某些数据库查询或某些复杂逻辑的执行。代替
var order = new Order
{
Id = 1001,
Reference = "Reference one"
};
order.SetCustomer(customerid);