INotifyPropertyChanged Setter Style
Posted
by
Ivovic
on Stack Overflow
See other posts from Stack Overflow
or by Ivovic
Published on 2011-06-21T07:56:30Z
Indexed on
2011/06/21
8:22 UTC
Read the original article
Hit count: 196
In order to reflect changes in your data to the UI you have to implement INotifyPropertyChanged, okay. If I look at examples, articles, tutorials etc most of the time the setters look like something in that manner:
public string MyProperty
{
//get [...]
set
{
if (_correspondingField == value)
{
return;
}
_correspondingField = value;
OnPropertyChanged("MyProperty");
}
}
No problem so far, only raise the event if you have to, cool. But you could rewrite this code to this:
public string MyProperty
{
//get [...]
set
{
if (_correspondingField != value)
{
_correspondingField = value;
OnPropertyChanged("MyProperty");
}
}
}
It should do the same (?), you only have one place of return, it is less code, it is less boring code and it is more to the point ("only act if necessary" vs "if not necessary do nothing, the other way round act").
So if the second version has its pros compared to the first one, why I see this style rarely? I don't consider myself being smarter than those people that write frameworks, published articles etc, therefore the second version has to have drawbacks. Or is it wrong? Or do I think too much?
Thanks in advance
© Stack Overflow or respective owner