属性获取器是否应该返回私有成员以外的值?

发布于 2024-10-18 01:47:24 字数 515 浏览 2 评论 0原文

private int _myField;
public int MyField
{
  get {
   return _myField * 99;
}
set {
   _myField * value;
}
}

我见过开发人员将更复杂的代码添加到 Getter 中,设置其他成员和属性等。对我来说,返回关联成员变量以外的值会导致调试混乱。

这样更好吗?

private int _myField;
public int MyField
{
  get {
   return _myField = _myField * 99;
}
set {
   _myField * value;
}
}

或者这个?

private int _myField;
public int MyField
{
  get {
   return _myField;
}
set {
   _myField = value * 99;
}
}
private int _myField;
public int MyField
{
  get {
   return _myField * 99;
}
set {
   _myField * value;
}
}

I've seen developers add more complex code into the Getter, setting other members and properties etc. To me return a value other than the associated member variable causes debugging confusion.

IS this better?

private int _myField;
public int MyField
{
  get {
   return _myField = _myField * 99;
}
set {
   _myField * value;
}
}

or this?

private int _myField;
public int MyField
{
  get {
   return _myField;
}
set {
   _myField = value * 99;
}
}

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

乄_柒ぐ汐 2024-10-25 01:47:24

这些都不好。在某些情况下,设置其他成员、执行缓存等是没问题的——毕竟,没有规则说属性必须由没有逻辑的成员变量支持,而验证就是其中之一。这是您需要其他逻辑的好例子。

然而,通常不是一个好主意是编写一个属性,以便获取刚刚设置的值将给出完全不同的答案。特别是,

foo.SomeProperty = foo.SomeProperty;

几乎应该从不做任何重要的事情(而在您的示例中它会改变值)。

(话虽如此,前两个示例的设置器代码已损坏。)

Neither of these are good. It's fine in some cases to set other members, perform caching, etc - there's no rule saying that a property has to just be backed by a member variable with no logic, after all, and validation is one very good example of where you'd want other logic.

However, it's usually not a good idea to write a property so that getting a value you've just set will give a radically different answer. In particular,

foo.SomeProperty = foo.SomeProperty;

should almost never do anything significant (whereas in your example it would change the value).

(Having said that, your setter code for the first two examples is broken.)

绝不放开 2024-10-25 01:47:24

我认为你的第二个片段完全违反了代码的语义。使用 getter 不应该影响公共值 - 也就是说,您可以在 getter 内部做任何您想做的事情,例如缓存或延迟初始化等 - 但在外部,对 getter 的两次连续调用应该返回相同的结果。

I think your second snippet is quite a violation of the code's semantics. Using a getter should not influence the public value - that is, you can do whatever you want inside the getter, such as caching or lazy initialisation and so on - but in the outside, two consecutive calls to the getter should return the same result.

枫以 2024-10-25 01:47:24

嗯,属性存在的原因之一是让你可以做这样的事情。属性是一种封装形式,使您能够隐藏需要对调用者隐藏的任何逻辑。

我个人的理念是,像你这样的东西很好(即不会产生副作用的简单数据操作),但是一旦逻辑变得比几行更复杂,你应该改用一种方法来向调用者表明更多的是正在进行中。

Well, one of the reasons properties exist is so that you can do stuff just like this. Properties are a form of encapsulation that give you the ability to hide any logic that you need to hide from the caller.

My personal philosophy is that stuff like you have is fine (i.e. simple data manipulation that doesn't create side effects) but once the logic gets more complex than a few lines you should change over to a method to indicate to the caller that more is going on.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文