tags:

views:

213

answers:

7

Possible Duplicate:
Properties vs Methods

Is there any rule or general best practice as to when to use a property vs a method? Technically any parameterless method can be made in a property and any property can be made a method, but sometimes when to decide when to use one of the other can be blurred.

I was hoping to get some rules you guys kept in mind when deciding between the two.

+8  A: 

The general standard is about side effects. If by calling a member to get a value you only get that value it's a property. If there are side effects, it should probably be a method.

To put it another way: properties even though they aren't fields should behave very much like fields. This means not causing side effects, not taking too long to execute and not throwing exceptions.

cletus
Not throwing exceptions? What would you do if the value set is an invalid value then? I thought that was kind of one of the reasons to use properties over fields... the ability to do checks on the value before accepting it.
Svish
+4  A: 

To add to what cletus has said.

This is from msdn: "Property Usage Guidelines" http://msdn.microsoft.com/en-us/library/bzwdh01d%28VS.71%29.aspx See the "Properties vs. Methods" section:

  • 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.
brian chandley
+1  A: 

use property when some er.. property is fast-performing (e.g. ctrl.Color, ctrl.Text, ctrl.Width, DateTime.Now). but if it signifies a process, use method (e.g. str.GetHash(), machine.GetFqdn(), file.GetMd5()). so in file md5, you will not make it a property

this emphasize it the most when to use a method:

The operation is expensive enough that you want to communicate to the user that they should consider caching the result.

do note that .NET's DateTime.Now, though fast as it is and a property, it needed be cached when it is called multiple times in your program, even near each other. they decided to make it a property, property has a feel of currentness in it, unlike when you call a method, it doesn't have a feel of instantness/currentness in it. so you need to take into account that even when you get a value and needed be cached, but if it needs to feel instant, by all means use property.

after all, if something is really fast and doesn't feel like an expensive operation, it has to have a construct that can convey its fastness. i think this is why .NET is attractive (or any language that has property construct), it doesn't force developers to use method when you can make it a property, it doesn't force developers to use method when you can make a performant code around overloaded operators, this is pragmatic programming at its best

Michael Buen
A: 

it's a good question. I don't know any best practice about this. In my opinion, it's usually a question of a common sense.

The proprieties are related to the object / class it self and usually describe it. Best example the UI element, Background, Color, IsEnabled are proprieties.

The methods are usually action that the object/class can perform and can make results. Best example here the method Show of a MessageBox. it do an action and return a result.

Zied
+3  A: 

I would take a look at this SO post on Properties vs Methods.
It mentions taking a look at Choosing Between Properties and Methods

SwDevMan81
A: 

At the fundamental level the decision between choosing a property or method depends upon 'has', 'does' argument. If the information you need is an attribute or quality go with properties. If it's an action then methods.

But at the practical level it can be hard to implement it this way all the time.

  • As it's been rightly pointed out, properties should be light weight, methods need not be.
  • If the information depends on some initialization code called in a constructor then you should prefer a property.
  • If your information needs a lot of operations, use methods.
  • If it affects a third element like a file, or the screen or something, use methods.
  • You can't have properties that don't return anything (void).
Cyril Gupta
A: 

Saying it with basic words, a property describes the object, while a method is an action the object can do. For an object that represent a car, drive() should be a method, and color should be a property.

kiamlaluno