Where should the line between property and method be?

Question

Possible Duplicate:
Properties vs Methods

For many situations it is obvious whether something should be a property or a method however there are items that might be considered ambiguous.

Obvious Properties:

• "name"
• "length"

Obvious Methods:

• "SendMessage"
• "Print"

Ambiguous:

• "Valid" / "IsValid" / "Validate"
• "InBounds" / "IsInBounds" / "CheckBounds"
• "AverageChildValue" / "CalcAverageChildValue"
• "ColorSaturation" / "SetColorSaturation"

I suppose I would lean towards methods for the ambiguous, but does anyone know of a rule or convention that helps decide this? E.g. should all properties be O(1)? Should a property not be able to change other data (ColorSaturation might change R,G,B values)? Should it not be a property if there is calculation or aggregation?

Just from an academic perspective, (and not because I think it's a good idea) is there a reason not to go crazy with properties and just make everything that is an interrogation of the class without taking an argument, and everything that can be changed about the class with a single argument and cant fail, a property?

Answer 1

In deciding whether to use a property or a method you should also consider the ammount of work the method involves. I.e. if it is relatively cheap to retrieve the value make it a property, if it costly make it a method.

Answer 2

I typically convert a property to a function if it has one of the following behaviors

• Causes a side effect (other than setting the backing field)
• Implementation is expensive when compared to say a field access
• Implementation has higher complexity than Log(N)
• Can throw an exception

Answer 3

I´ve found some interesting text about this

MSDN | Properties vs Methods

EDIT

It says things like:

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.

Answer 4

Another consideration is bindability. Most frameworks can bind only to properties. For example, if you want IsValid to be usable in binding (say, as a binding sourcee for the OK button's IsEnabled property), then it has to be a property rather than a method.

Answer 5

If you can calculate something from what you already have, use methods, if your value has to be a basis for operating with or calculating something else it should be property.

For example, if you want to check whether certain user input is up to date and you can do it with your unique patented algorithm, use method Validate(). If user just sends you a form submitting nis current address is valid, use property valid. But it is just a common approach that may vary depending on what you actually want.

Answer 6

I've always leaned towards using methods over properties for several reasons:

• Using a method guarantees/improves API stability. Let's say you have a method setName that sets the name of the item. Initially, you might simply set the property name to whatever the new name is. However, later you might need to validate the parameter against a regular expression because a name should only contain specific characters. If you initially let the property be changed directly, you'd have to change every reference to setName; by using a method, you don't need to change the API at all.

• When using inheritance, it might be better to have a setter function you can override for many of the same reasons listed above.

• Directly setting properties means you cannot add your own debugging as easily. I've found there are many situations where you might want to put an output statement in every setName method call while you test everything, which isn't always possible when you directly set the property. While certain languages do have debuggers that can do this, using methods is a cross-language guarantee.

Answer 7

I personally make the choice on complexity and what the method/property is going to do. If I'm all doing is setting a value, ie _name = something;, then I go with a property. Even if I'm going to do some very basic calculations or conditional statements I will stick with a property. But if something is going to need some serious work or even moderate work I would use a method. Nothing aggrevates me more then setting a property and suddenly a whole bunch more code than I expected gets executed.