实现简单属性时,您可以使用auto-implemented properties,使代码看起来更简单,如下所示:
public int MyInt
{
get; set;
}
或者您可以使用“手动”私有字段来实现它。在这种情况下,我经常看到人们在使用set
之前检查值的变化。像这样:
private int _myInt;
public int MyInt
{
get { return _myInt; }
set
{
if value != _myInt
_myInt = value;
}
}
所以我的问题是这样的:检查改变的值(在后一种情况下)对任何事情都有好处吗?如果是,那么这会对自动实现的属性产生什么影响?
答案 0 :(得分:3)
在实施INotifyPropertyChanged
时,您将使用该检查
(您希望仅在属性的值实际更改时触发事件,而不是仅在调用setter时触发。)
答案 1 :(得分:1)
您无法同时执行这两项操作,请使用自动实现的属性并检查其值。只要将任何逻辑引入getter或setter,它就不再是自动实现的属性。
auti-implementation属性只是访问私有后备字段的getter / setter的语法糖,就像你写这个:
public int MyInt
{
get { return _myInt; }
set { _myInt = value; }
}
当您想要检查新值是否有效时,您 使用具有某些逻辑的setter。例如,您可能想要检查您的整数是否为正,因为您的应用程序无法处理负值。所以你只需在setter中引入该检查。
set
{
if (value >= 0)
_myInt = value;
}
另外,你不能只定义一个部分(即getter 或 setter),你必须用大括号定义它们。另一方面,你当然可以完全省略其中一个,使你的属性只读或只写(虽然我几乎不能想到后者的任何使用)。实际上,甚至属性都是get-和set-method的语法糖。所以你可以把它们想象成通常的方法。你为什么不在那里引入任何逻辑?当然,属性倾向于让人们认为在他们的制定者或吸气者中没有发生什么特别的事情,这也是公约所暗示的。然而,除了在自动实现属性上你只是访问一个你无法在代码中访问的后备字段这一事实,它实际上并没有什么特别之处,因为它的名称并不为IDE所知,但它存在在IL as shown here内。
编辑:回到你的问题。如果您在setter中或在它之前引入验证新值的逻辑,它将不会产生真正的区别,因此您也可以写下:
int newValue = -1;
if(newValue >= 0)
myInstance.MyInt = newValue;
但是这可能会非常混乱,特别是在您需要在代码中的其他位置设置属性并再次检查时,会打破DRY - priniciple。所以最好这样做once, and only once(在制定者中)。
答案 2 :(得分:1)
检查更改后的值(在梯形图中)是否适合任何事情?
不是,至少在您提供的示例中没有。好吧,除非你有一个代码在一个巨大的循环(数十万)中分配给属性,在这种情况下,如果检查值比分配快几毫秒,那么你会看到明显的差异。我说"如果",因为我不确定int
的情况,所以如果你对答案感兴趣,你必须测试它
然而,在其他情况下,可能会有明显的差异。例如,如果setter不仅仅是分配值。
答案 3 :(得分:1)
假设MyInt
是X
鼠标的位置,你有一个无限循环,每个毫秒都会占用鼠标位置,并显示在窗口上。如果你不检查你必须每毫秒更新窗口,当你的鼠标静止不动时。
大多数情况下您不需要检查,即使它是相同的value
,值也会更改。当您遇到性能问题时,请执行此操作。