views:

117

answers:

5

Hi All,

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.

+12  A: 

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");
                }
           }
      }
 }
Pieter Breed
+1..i agree with this answer, but in his example there was no mention of RaisePropertyChanged or any events for that matter.
Stan R.
That's a good point!
Quagmire
I have myself ofter looked at some example code and missed a crucial part of it. I am offering a possible explanation which might highlight the missing/forgotten/overlooked bits
Pieter Breed
@Stan, aren't we being a bit nitpicky? I can't imagine any other scenario where this might be useful.
Robert Harvey
@Pieter: good assumption. RaisePropertyChangedEvent was not used in this particular bit of code, but it is used in other areas of the application. Perhaps this was done for consistency? Thanks for the clarification. +1
Robert
A: 

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.

Stan R.
A: 

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.

Quagmire
+1  A: 

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.

jphofmann
A: 

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.

Corne
Thanks for catching my typo. It is now fixed.
Robert
But then if testID was so complex that setting it would be expensive, chances are pretty good that testing would also be very expensive.
Jeff Hornby