views:

694

answers:

7

This is probably a matter of personal preference, but when do you use properties instead of functions in your code

For instance to get an error log I could say

string GetErrorLog()
{
      return m_ErrorLog;
}

or I could

string ErrorLog
{
     get { return m_ErrorLog; }
}

How do you decide which one to use? I seem to be inconsistent in my usage and I'm looking for a good general rule of thumb. Thanks.

+30  A: 

I tend to use properties if the following are true:

  • The property will return a single, logic value
  • Little or no logic is involved (typically just return a value, or do a small check/return value)

I tend to use methods if the following are true:

  • There is going to be significant work involved in returning the value - ie: it'll get fetched from a DB, or something that may take "time"
  • There is quite a bit of logic involved, either in getting or setting the value


In addition, I'd recommend looking at Microsoft's Design Guidelines for Property Usage. They suggest:

Use a property when the member is a logical data member.

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. Properties that return arrays can be very misleading. Usually it is necessary to return a copy of the internal array so that the user cannot change internal state. This, coupled with the fact that a user can easily assume it is an indexed property, leads to inefficient code. In the following code example, each call to the Methods property creates a copy of the array. As a result, 2n+1 copies of the array will be created in the following loop.
Reed Copsey
I'd add that your methods should have only one responsibility. Don't create massive methods this reams of code doing different things. Split each different work into private methods or even in methods in another class
skyfoot
Zoooom!! Answered and got 12 upvotes in 5 mins.
AnthonyWJones
@AnthonyWJones: That's always a nice surprise when it happens :)
Reed Copsey
@skyfoot: True, but often, you'll want one method that calls into multiple methods in order to specify a specific order of execution. I agree - they should be refactored into small parts, but for the purpose of choosing between property and method, the TOTAL execution happening within the method (even if it's calling another, which calls another, etc) is important to consider.
Reed Copsey
I'd add to the above list that the member should be a property if it needs to be exposed to data binding.
Robert Rossney
+6  A: 

Here are Microsoft's guidelines:

Choosing Between Properties and Methods

Kyralessa
+4  A: 

See Property Usage Guidelines from the MSDN.

Romain Verdier
+1  A: 

I'd never use a property if I could be affecting more than one field - I'd always use a method.

Generally, I just use the public string ErrorLog { get; private set; } syntax for Properties and use Methods for everything else.

ssg31415926
+1  A: 

In addition to Reed's answer when the property is only going to be a getter like getting a resource such as an Event Log might be. I try and only use properties when the property will be side effect free.

JoshBerke
+1  A: 

If there is more than something trivial happening in a property, then it should be a method. For example, if your ErrorLog getter property was actually going and reading files, then it should be a method. Accessing a property should be fast, and if it is doing much processing, it should be a method. If there are side affects of accessing a property that the user of the class might not expect, then it should probably be a method.

There is .NET Framework Design Guidelines book that covers this kind of stuff in great detail.

AaronLS
+3  A: 

I use properties when its clear the semantic is "Get somevalue from the object". However using a method is a good way to communicate "this may take a bit more than a trivial effort to return".

For example a collection could have a Count property. Its reasonable to assume a collection object knows how many items are currently held without it actually having to loop through them and count them.

On the hand this hypothetical collection could have GetSum() method which returns the total of the set of items held. The collection just a easily have a Sum property instead but by using a method it communicates the idea that the collection will have to do some real work to get an answer.

AnthonyWJones