views:

360

answers:

2

Is there ever a situation where I should do the following in .NET instead of using a property with read/write capability?

private S as string

public function GetS() as string
     return S
end function

public sub SetS(byval NewS as string)
    S = NewS
end function

Do properties simply provide a more efficient way for doing the same thing?

Will properties be any slower than the above accessor functions in a high performance application?

+5  A: 

Properties, internally, are nothing but a pair of methods. They basically evaluate to a get and set accessor method.

You should use properties, unless the property is going to cause some unexpected, potentially long running side effect, or there is some other good reason to use a method.

For details, I suggest reading the Property Usage Guidelines on MSDN. In particular, use a method when:

  • The operation is a conversion, such as Object.ToString.
  • The operation is expensive enough that you want to communicate to the user that they should consider caching the result.
  • Obtaining a property value using the get accessor would have an observable side effect.
  • Calling the member twice in succession produces different results.
  • The order of execution is important. Note that a type's properties should be able to be set and retrieved in any order.
  • The member is static but returns a value that can be changed.
  • The member returns an array.

Otherwise, I'd use a property. Brad Abram's blogged some other details, including good reasons why certain API functions use methods (mostly because they could cause cross-computer communication, which would fall into the "side effect" category).

Reed Copsey
Unfortunately this rule is often broken in the .NET Framework itself...
empi
@Reed - Why would anybody ever need a Private Property?
hamlin11
It makes it easier to add logic that occurs when things are done, plus eases versioning (if later, you decide you need to have extra logic set in there). Simple properties get inlined by the JIT, so there is little reason to avoid using them. Also, private properties can work with data binding.
Reed Copsey
"The member returns an array" should really be generalized to "member returns a mutable object of reference type that is no longer owned by the object to which that member belonds".
Pavel Minaev
@Reed - That helps a bit. It sounds like you would be providing a bit of a wrapper to the internals of an object. Maybe not the smartest thing to do for a simple string or integer member, but may be quite useful for capturing some meta information about an object. Am I on the right path for property's intended usage? Thanks for the links above.
hamlin11
Yes. It's a good idea to do, if you think you might ever want to provide the "wrapper". For example, if later, you want to implement INotifyPropertyChanged, or have some other change tracking, having the private as a property is useful, since you can change that without changing other code.
Reed Copsey
+2  A: 

Properties are actually syntactic sugar for methods called get_MyProperty and set_MyProperty, so there is no performance difference.

GraemeF