[ulent]

Hey fellas and fellettes, quick question..

If I store a constructor parameter's value inside a field and then want to use the value again inside the constructor, is there any reason to use the parameter vs. the field value?

Possible reasons I thought of might be convention, faster memory access, etc.

eg.

public class Shape
{
  bool _myVal;

  public Shape(int myVal)
  {
    _myVal = myVal;
    
    // is this better...
    if (myVal)
    {
      //do something
    }

    // ...than this?
    if (_myVal)
    {
      //do something
    }
  }
}

Thanks

[tlhIn`toq]

Just get used to doing everything through parameters.
It will keep you from having to shift your coding style later.
It will keep everything in your code the same, which helps your sanity.

I can't tell you how many times I've said "Oh, I'll just use a field here" then had to go back and change it to a parameter because either:

• It shifted from private to public use
  
• It needed to validate the incoming value (do that in the set{})
  
• You want to serialize it to XML
  
• You want to data bind it to some other object 3 months from now.
  
• You want to shift from WinForms to WPF which loves data binding.

[ulent]

Thanks for the quick response

This may be a n00bish thing to ask - but are we talking about properties rather than parameters here? (I didn't know you could do set { } on a parameter).

When I think parameter I'm parameters to a function call, eg.

foo(int a, string B)/>

as opposed to what I was thinking wrt Properties:

public Foo
{
  get { /* getter logic */ }
  set { /* setter logic */ }
}
[code]

If it's the latter then I totally agree, and that clears it up nicely (assuming I'm not, in fact, just drunk on unicorn juice). So as opposed to my first post you'd recommend...

[code]
Shape myShape = new Shape { MyVal = true };

.. where Shape is ...

public class Shape
{
  public bool MyVal
  {
    get { }
    set { }
  }

  public Shape()
  {
    if (MyVal)
    {
      // do something
    }
  }
}

... allowing databinding etc. where MyVal would be a SelectList or something similar?

Oops, rogue

 tag. What I *meant* to say...

[code]
public Foo
{
  get { /* getter logic */ }
  set { /* setter logic */ }
}

If it's the latter then I totally agree, and that clears it up nicely (assuming I'm not, in fact, just drunk on unicorn juice). So as opposed to my first post you'd recommend...

Shape myShape = new Shape { MyVal = true };

Woah, fail. Somehow my two posts just got merged?

[tlhIn`toq]

Sorry for the confusion. I was referring to the use of the field at all
03 bool _myVal;

This is what I was suggesting should be a property.'


As far as your sample goes of parameter myVal versus setting a class-wide field or property... That only matters if you plan to re-use the parameter later. If it only needs to live within the constructor then don't complicate the design. But if you need that value in other methods then you have no choice but to set a class-wide property or field because the parameter is going to be disposed of as soon as the constructor method finishes.

[ulent]

Ahh right, I'm with you now. My bad, I should have mentioned the value needs to persist beyond the constructor.

In that case, would you cast your vote in favor of implementing it as a property? I feel kinda like that's the most C#-ish way to go about it.

In my case I just need a simple boolean flag across the class to switch some behavior on/off - ie. it's not going to get any logic attached to it in get/set. But I guess that's what they all say.

I kind of see the field as a 'lightweight' version since it's a memory lookup rather than a function call like is required for the Property getter. My further thinking was that if I was going to set a field in the constructor, then use that field (within the constructor) it may be slightly faster to use the local variable as it's already on the stack (obviously other methods in the constructor would require using the property/field due to the constructor's local variable being out of scope).

This is all probably just me being stupidly over-zealous, but I'd love any opinions on usability/readability/speedability on any of the above. Thanks for the replies, they've got me thinking..

[tlhIn`toq]

In your class you keep it as a property.
You still receive it as a parameter of the constructor as you have done here (with minor upgrade to the example):

public class Shape: INotifyPropertyChanged
{
  private  int _myVal;// backing field
  public int MyVal
  { 
     get { return _myVal; }
     set 
     {
         // Validate and normalize
         if (value < acceptableMin) value = acceptableMin;
         if (value > acceptableMax) value = acceptableMax;
         if (_myVal != value)
         {// If they are already equal, then don't raise a change event because there is no real change
             _myVal = value;
             RaisePropertyChangedEvent("MyVal");
     }

  public Shape(int myVal)
  {
      this.MyVal = myVal; // Let the property take care of the rest of the validation and logic.
  }
}

[ulent]

Nice example, thanks for the input.

[Momerath]

ulent, on 18 June 2012 - 03:07 PM, said:

Possible reasons I thought of might be convention, faster memory access, etc.

Late to this conversation, but just wanted to add that you shouldn't be worrying about speed at this point in your code. For 99% of the applications done, you'll never have to optimize them for speed. For the other 1% you get it working first, then go back and optimize (and you use a profiler, most of the time what you think is slow isn't what is slowing down your code).

This, of course, assumes you make good choices in algorithms, which is why it's important to understand them

[ulent]

Good point, and I do need to spend more time getting into code profiling, thanks for the reminder.

I guess I was thinking more in terms of - if I have a choice between two (or three) options and it's no more labor-intensive to implement one over the others, it makes sense to figure out at some point which is the optimal option so it becomes an automatic choice from the Bag Of Tricks in the future.

However, I can definitely can see your point in the case where the application doesn't start yet because the logger's been refactored five times.