C#中的属性应该执行很多工作吗? [英] Should properties in C# perform a lot of work?

问题描述

从属性中读取或分配属性时，不会期望它执行大量工作.当改用 setSomeValue(...)和 getSomeValue(...)方法时，不要感到惊讶的是，在兜帽.但是，既然C#为世界提供了 Properties ，那么改用getter和setter方法似乎很愚蠢.你对此有什么看法?我应该将此问号标记为社区Wiki吗?

When a property is read from or is assigned to, one would not expect it to perform a lot of work. When setSomeValue(...) and getSomeValue(...) methods are used instead, one should not be that surprised that something non-trivial might be going on under the hood. However, now that C# gave the world Properties, it seems silly to use getter and setter methods instead. What is your take on this? Should I mark this Q as a community wiki?

谢谢.

就我而言，调用并不昂贵，但会触发在另一个类中设置相关属性，并可能在日志文件中写入一条短消息(如果URL为空).物业需要太多工作吗?有什么选择.

In my case it is not expensive to call, but it triggers setting a related property in another class and possibly writing a short message to a log file (if URL is blank). Is that too much work for a property? What is the alternative.

推荐答案

但是，现在C#给了世界属性，使用起来似乎很愚蠢而是使用getter和setter方法.

However, now that C# gave the world Properties, it seems silly to use getter and setter methods instead.

在考虑应该有多昂贵的属性之前，我建议您考虑一下是否将要建模的概念最好地表示为某物的属性".属性以表示该语言的语言存在其他实体的归属-如果 SomeValue 在逻辑上不是其所属类型的属性，则应考虑改用getter/setter方法.

Before thinking about how expensive properties should be, I would advise you to think about whether the concept you are modeling is best represented as a "property of something". Properties exist in the language to express attribution of other entities - if SomeValue is not logically a property of the type it belongs to, then you should consider using getter/setter methods instead.

C#中的属性应该发挥很多作用工作吗?

Should properties in C# perform a lot of work?

话虽如此，它有助于使属性尽可能地便宜.大多数开发人员都希望属性可以有效地包装它们所属的某些内部状态.违反此期望会使开发人员更难编写使用该属性的性能良好的代码.例如，如果将某个属性用作 for 循环的条件，则将在每次迭代时对其进行评估-如果代价很高……那可能是不好的.

Having said that, it helps to make properties inexpensive when possible. Most developers expect properties to be efficient wrappers around some internal state of the type they belong to. Violating this expectation makes it harder for developers to write well performing code that uses the property. For example, if a property is used in as a condition of a for loop it will be evaluated on each iteration - if it's expensive ... well that can be bad.

属性也经常在调试器中访问-您不希望属性执行昂贵的逻辑，因为这会抑制调试.执行带有副作用的操作(例如，例如查询数据库)的属性获取器通常也是一种不好的做法，因为它们会引入

Properties are also often accessed in the debugger - you don't want properties to perform expensive logic as this can inhibit debugging. Property getters that perform operations with side effects (like querying a database, for example) are generally a bad practice as well, because they can introduce heisenbugs when inspecting the behavior of an application in the debugger.

有什么选择.

您可能还想阅读此内容答案，它为物业设计提供了一些良好的一般准则.我还建议您阅读在属性和方法之间进行选择MSDN上的.NET设计指南.

You may also want to read up on this answer which provides some good general guidelines for property design. I would also advise you to read Choosing Between Properties and Methods in the .NET design guidelines on MSDN.

有时候创建一个只读属性(没有设置器)是有意义的，但是存在一个或多个单独的方法来设置与该属性相关的内部状态.是否使用此惯用语取决于对象上的操作在语义上显示为状态改变" 还是执行活动" .当是后者时，我倾向于使用方法(而不是属性设置器)来表达这种行为.

Sometimes it makes sense to create a property which is read-only (no setter) but where one or more separate methods exist that set the internal state related to that property. Whether to use this idiom depends on whether the operations on your object are exposed semantically as "changing state" or "performing activity". When it's the latter, I tend to use methods (rather than property setters) to express this behavior.

这篇关于C#中的属性应该执行很多工作吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！