Properties vs Methods

Question

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.

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.

Properties are a way to inject or retrieve data from an object. They create an abstraction over variables or data within a class. They are analogous to getters and setters in Java.

Methods encapsulate an operation.

In general I use properties to expose single bits of data, or small calculations on a class, like sales tax. Which is derived from the number of items and their cost in a shopping cart.

I use methods when I create an operation, like retrieving data from the database. Any operation that has moving parts, is a candidate for a method.

In your code example I would wrap it in a property if I need to access it outside it's containing class:

public Label Title 
{
   get{ return titleLabel;}
   set{ titleLabel = value;}
}

Setting the text:

Title.Text = "Properties vs Methods";

If I was only setting the Text property of the Label this is how I would do it:

public string Title 
{
   get{ return titleLabel.Text;}
   set{ titleLabel.Text = value;}
}

Setting the text:

Title = "Properties vs Methods";

Searching through MSDN, I found a reference on Properties vs Methods that provides some great guidelines for creating methods:

• 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.

If you're setting an actual property of your object then you use a property.

If you're performing a task / functionality then you use a method.

In your example, it is a definite property being set.

If however, your functionality was to AppendToLabel then you would use a method.

Symantically properties are attributes of your objects. Methods are behaviors of your object.

Label is an attribute and it makes more sense to make it a property.

In terms of Object Oriented Programming you should have a clear understanding of what is part of behavior and what is merely an attribute.

Car { Color, Model, Brand }

A car has Color, Model and Brand attributes therefore it does not make sense to have a method SetColor or SetModel because symantically we do not ask Car to set its own color.

So if you map the property/method case to the real life object or look at it from symantic view point, your confusion will really go away.