Properties vs Methods

Question

Quick question: When do you decide to use properties (in C#) and when do you decide to use methods?

We are busy having this debate and have found some areas where it

Answer 1

From the Choosing Between Properties and Methods section of Design Guidelines for Developing Class Libraries:

In general, methods represent actions and properties represent data. Properties are meant to be used like fields, meaning that properties should not be computationally complex or produce side effects. When it does not violate the following guidelines, consider using a property, rather than a method, because less experienced developers find properties easier to use.

Answer 2

Here is a good set of guidelines for when to use properties vs methods from Bill Wagner

• Use a Property when all these are true: The getters should be simple and thus unlikely to throw exceptions. Note that this implies no network (or database) access. Either might fail, and therefore would throw an exception.
• They should not have dependencies on each other. Note that this would include setting one property and having it affect another. (For example, setting the FirstName property would affect a read-only FullName property that composed the first name + last name properties implies such a dependency )
• They should be settable in any order
• The getter does not have an observable side effect Note this guideline doesn't preclude some forms of lazy evaluation in a property.
• The method must always return immediately. (Note that this precludes a property that makes a database access call, web service call, or other similar operation).
• Use a method if the member returns an array.
• Repeated calls to the getter (without intervening code) should return the same value.

• Repeated calls to the setter (with the same value) should yield no difference from a single call.

• The get should not return a reference to internal data structures (See item 23). A method could return a deep copy, and could avoid this issue.

*Taken from my answer to a duplicate question.

Answer 3

Also big plus for Properties is that value of property can be seen in Visual Studio during debugging.

Answer 4

I prefer to use properties for add/set methods with 1 parameter. If parameters are more, use methods.

Answer 5

I only use properties for variable access, i.e. getting and setting individual variables, or getting and setting data in controls. As soon as any kind of data manipulation is needed/performed, I use methods.

Answer 6

Yes, if all you're doing is getting and setting, use a property.

If you're doing something complex that may affect several data members, a method is more appropriate. Or if your getter takes parameters or your setter takes more than a value parameter.

In the middle is a grey area where the line can be a little blurred. There is no hard and fast rule and different people will sometimes disagree whether something should be a property or a method. The important thing is just to be (relatively) consistent with how you do it (or how your team does it).

They are largely interchangeable but a property signals to the user that the implementation is relatively "simple". Oh and the syntax is a little cleaner.

Generally speaking, my philosophy is that if you start writing a method name that begins with get or set and takes zero or one parameter (respectively) then it's a prime candidate for a property.