那里有很多建议你不应该公开地公开你的字段,而是使用普通的属性.我一遍又一遍地看到它.
我理解这些论点,但在大多数情况下我认为这不是一个好建议.
有没有人有一个真正重要的时间的例子？在写一个琐碎的财产时,将来可能会有一些重要的事情(或者当没有使用它时会让他们陷入真正的麻烦)？
编辑:DataBinding参数是正确的,但不是很有趣.DataBinding代码中的一个错误是它不接受公共字段.因此,我们必须编写属性来解决该bug,而不是因为属性是明智的类设计选择.
编辑:要清楚,我正在寻找现实世界的例子,而不是理论.真正重要的时刻.
编辑:在setter上设置断点的能力似乎很有价值.为调试器设计我的代码是不幸的:我宁愿调试器变得更聪明,但考虑到我们的调试器,我将采用这种能力.好东西.
在不确定的未来可能很难使代码工作,但这不是懒惰的借口.在字段上编码属性是惯例,它是务实的.称之为防御性编程.
其他人也会抱怨速度问题,但是JIT'er足够聪明,能够像暴露公共场地一样快.足够快,我永远不会注意到.
想到一些非平凡的事情
公共字段完全公开,您不能强制使用只读或只写语义
属性可以有有不同的get对set可访问性(如公共获取,内部设置)
您不能覆盖字段,但可以拥有虚拟属性.
你的班级无法控制公共领域
你的班级可以控制财产.它可以将设置限制为允许的值范围,标记状态已更改,甚至延迟加载值.
反思语义不同.公共领域不是财产.
没有数据绑定,正如其他人指出的那样.(这只是你的一个错误. - 我能理解为什么.net框架设计师不支持他们不赞成的模式.)
您不能在接口上放置字段,但可以在接口上放置属性.
您的房产甚至不需要存储数据.您可以创建外观并分派到包含的对象.
您只需输入额外的13个字符即可.这似乎不像是投机性的普遍性.存在语义差异,如果没有别的,属性具有不同的语义含义,并且比公共字段更灵活.
public string Name { get; set; }
public string name;
我记得有一次第一次使用.net时,我将几个类编码为只是字段,然后由于某种原因我需要将它们作为属性,而且当我第一次完成它时,完全浪费时间时间.
那么你有什么理由不遵守惯例呢？为什么你觉得需要游泳上游？没有这样做,它为你节省了什么？
我有一个简单的属性,在调试时保存了几次..Net不支持数据断点(读或写)的概念.有时,在调试非常复杂的场景时,跟踪对特定属性的读/写非常重要.这对于一个属性很容易,但是对于一个领域来说是不可
如果您不在生产环境中工作,则可以很容易地重构字段 - >属性以进行调试.偶尔会遇到只能在生产环境中重现的错误,这些错误很难使用新的二进制文件进行修补.物业可以救你.
但这是一个相当有限的情况.
杰伊,我曾经想过同样的事情.为什么要使用一个属性,只有那里提供直接访问私人会员？如果你可以把它描述为一个自动装置,那么拥有一个属性而不是一个领域似乎有点愚蠢.即使您需要更改实现,您也可以随后重构为不动产,任何相关代码仍可正常工作,对吧？好吧,也许不是.
你看,我最近看到了关于琐碎属性的亮点,所以也许现在我可以帮你做同样的事情.
最终让我信服的是相当明显的一点(回想起来).Net中的属性只是getter和setter方法的语法糖,而这些方法与属性本身有不同的名称.同一个程序集中的代码仍然有效,因为无论如何都必须同时重新编译它.但是,如果您将字段重构为属性,则链接到您的不同程序集中的任何代码都将失败,除非它同时针对您的新版本重新编译.如果它是一个从一开始的财产,一切都还是不错的.
部分原因是这些属性在将来可能不会是微不足道的 - 如果将外部代码绑定到某个字段然后想要将其包装在属性中,则所有相关代码都必须更改,并且您可能无法要做到这一点,特别是在你是一名控制设计师或有你无法控制的图书馆等的情况下.
更不用说某些.NET实践不允许您特别使用字段 - 数据绑定.
我相信还有其他好的理由.为什么这对你很重要？使用自动属性并完成它.似乎不值得关注的事情......
我会用另一个问题回答你的问题:你是否真的受益于不让所有类型和成员公开？我怀疑我没有通过这样做直接防止任何错误.但是,我已经正确地封装了我的类型,只暴露了暴露的内容.属性是相似的 - 好的设计比什么都重要.我认为属性在概念上与字段不同; 它们是合同的一部分,而不是从根本上实施的一部分.将它们视为属性而不是字段有助于我更清楚地思考我的设计,从而产生更好的代码.
哦,我偶尔从不破坏源兼容性,能够设置断点,日志访问等方面受益.
京公网安备 11010802040832号 | 京ICP备19059560号-6 