It's a good question indeed but I do have a few concerns with the design of the properties you're describing. If setting one property causes another property's value to be changed as well, this is pretty much to be considered as a side-effect
and maybe a property isn't the best choice in that case (in more complicated situations you'll have to make sure you're not causing a cycle in the chain of setter calls). For more info, check the Framework Design Guidelines on
Choosing Between Properties and Methods
Nevertheless, there's no silver bullet to this kind of problems - the one thing that's key is to be
. Concerning your WPF sample, I'd rely on the SelectedWidget property to become null automatically.
There are a million reasons properties would behave the way I described. Some simple examples:
DueDate and DaysPastDue. These are variations on the same data. A change to one thus is a change to the other. With little thought you can think of a lot of other examples that fall along these lines. For example, think of a Rectangle and the correspondance
between the corner coordinates and the width and height.
When following the M-V-VM pattern, you'll typically have (for example) a Widgets collection and a SelectedWidget. A change to the Widgets collection can effect the SelectedWidget property. Those are just a few examples.
I'm not denying these are side effects, I'm denying the assertion that properties shouldn't have side effects.