在Property Setter中，只有在价值不同时设置才有利吗？

Question

I'm wondering what benefits this code has:

    private int _TestID;
    public int TestID
    {
        get 
        { 
            return _TestID;
        }
        set
        {
            if(_TestID != value)
            {
                _TestID = value;
            }
        }
    }

vs. this:

    private int _TestID;
    public int TestID
    {
        get 
        { 
            return _TestID;
        }
        set
        {
            _TestID = value;
        }
    }

It seems to me that this was done in the name of efficiency (only setting if different), but wouldn't the test take as long (or longer) that the initial set? I'm not sure if I'm missing something here, but would love to hear any comments and explanations.

Answer 1

It is useful when you combine it with a RaisePropertyChanged("TestID") (inside the if, after the field value is set) event pattern often seen with WPF or other databinding solutions.

class Something : INotifyPropertyChanged
{
      public int TestID 
      {
           get { return testId; }
           set 
           {
                if (testId != value)
                {
                     testId = value;
                     RaisePropertyChangedEvent("TestID");
                }
           }
      }
 }

Answer 2

This is the type of optimization I will happily leave to the compiler. I would hate to "force" an efficiency that may or may not be true in every situation.

Answer 3

Really I would think that the first example would cause more problems when it comes to complex types and operator overloading. In this particular case the first example is fairly pointless.

Answer 4

If performance is the only issue here, I would choose the first one.... Even IF there is a difference in performance, it will be too small to notice.

It's also a needless expansion of lines of code.

Answer 5

I think the example code you gave is not fully correct. Did you mean this?

private int _TestID;
public int TestID
{
    get
    {
        return _TestID;
    }
    set
    {
        if (_TestID != value)
        {
            _TestID = value;
        }
    }
}

The reason for this construction is not clear to me either. If however _TestID would be a property instead of an int then this construction could be beneficial because setting _TestID could in this case be an expensive operation.