using access to a field from a passed object

[Tony Johansson]

Hello!

Below I have method MostPowerful which is located in class SportsCar.
As you can see the fomel parameter for method MostPowerful is carCompare of
class SportsCar.
Because this method MostPowerful is a member of class SportsCar
can I use the field directly for the passed SportsCar object in
this way "carCompare.horsepower".

Now to my question. I have two choices. I wonder which is best according to
OOP.
1. Use the field directly as I have done by using this statement
"carCompare.horsepower"
2 Or use a property to get the horsepower. Like carCompare.GetHorsepower or
somthing similar

Is the performance between using 1 or 2 about the same?


public SportsCar MostPowerful(SportsCar carCompare)
{
if (carCompare.horsepower > this.horsepower)
return carCompare;
else
return this;
}


//Tony

 

[Peter Duniho]

[...]
Now to my question. I have two choices. I wonder which is best according to
OOP.
1. Use the field directly as I have done by using this statement
"carCompare.horsepower"
2 Or use a property to get the horsepower. Like carCompare.GetHorsepower or
somthing similar

Is the performance between using 1 or 2 about the same?

It should be identical, assuming your property getter is just something
like "return horsepower;", since it would be inlined.

As far as which is better, I would generally prefer to use the property
to access the field. Presumably the code comparing the two values
doesn't or shouldn't care about the implementation of the property, so
using the underlying field seems unnecessary and potentially
restrictive.

I would never name a property with the word "Get", for a variety of
reasons but the most obvious being that a property can be both assigned
and retrieved (set and get). It would look kind of odd to have code
that reads like "carCompare.GetHorsepower = horsepowerNew;". Just name
the property something that describes what it is, like "Horsepower".

Pete

 

[Chris Shepherd]

I would never name a property with the word "Get", for a variety of
reasons but the most obvious being that a property can be both assigned
and retrieved (set and get). It would look kind of odd to have code
that reads like "carCompare.GetHorsepower = horsepowerNew;". Just name
the property something that describes what it is, like "Horsepower".

Actually, Microsoft's guidelines on how to name Type members basically
says don't do this -- in other words, you should use verbs/verb phrases
for methods, and noun/noun phrases/adjectives for Properties.

http://msdn2.microsoft.com/en-us/library/ms229012.aspx

Chris.

 

[bryan]

Actually, Microsoft's guidelines on how to name Type members basically
says don't do this -- in other words, you should use verbs/verb phrases
for methods, and noun/noun phrases/adjectives for Properties.

http://msdn2.microsoft.com/en-us/library/ms229012.aspx

Hmm. Are you implying that the Microsoft guidelines say NOT to call the
property "Horsepower", or are you agreeing with Peter?

Horsepower is a noun, so it is perfectly suited for use as a Property name
in the guidelines to which you referred.

 

[bryan]

Make and use a property. That way if you change the nature of the field but
can still obtain and return the Horsepower value, the property can still
return the value and users of the class won't need to change thier code.

 

[Chris Shepherd]

Hmm. Are you implying that the Microsoft guidelines say NOT to call the
property "Horsepower", or are you agreeing with Peter?

Horsepower is a noun, so it is perfectly suited for use as a Property name
in the guidelines to which you referred.

Sorry, I had re-written some of that for clarity and actually
accomplished the reverse (failed to remove "actually"). I was agreeing
with Peter.

Chris.