When to Use Properties Instead of Functions

When to use properties instead of functions

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.

Properties vs Methods

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.

Why do we use .NET properties instead of plain old get/set functions?

Jon Skeet has an excellent overview on his C# article blog about why properties matter. In it he explains why properties should be used over exposing public fields.

As for why to use properties instead of getter/setter methods, I would suggest the following thoughts:

Properties provide a cleaner, more concise syntax that is easy to understand and read.
Properties enable assignment expression chaining: A.x = B.y = C.z
Properties convey the semantics of data access clearly and consistently - consumers expect that there are no side effects.
Properties are recognized by many libraries in .NET for tasks such as XML serialization, WPF bindings, ASP.NET 2-way binding, and more.
Properties are recognized by the IDE and many visual designers and can be displayed in a property editor.
Properties enable support for the increment (++) and decrement (--) operators.
Properties can be easily differentiated from methods using reflection and allow dynamic consumers to extract knowledge about the data exposed by an object.
C# 3 supports automatic properties which helps eliminate boilerplate code.

.NET - When should I use a property vs. variable + accessor function?

Properties, internally, are nothing but a pair of methods. They basically evaluate to a get and set accessor method.

You should use properties, unless the property is going to cause some unexpected, potentially long running side effect, or there is some other good reason to use a method.

For details, I suggest reading the Property Usage Guidelines on MSDN. In particular, 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.

Otherwise, I'd use a property. Brad Abram's blogged some other details, including good reasons why certain API functions use methods (mostly because they could cause cross-computer communication, which would fall into the "side effect" category).

When is it preferable to use getters instead of functions in Dart?

You can read from the effective dart guide:

DO use getters for operations that conceptually access properties.

The operation does not take any arguments and returns a result.
The caller cares mostly about the result.
The operation does not have user-visible side effects.
The operation is idempotent.
The resulting object doesn’t expose all of the original object’s state.

When to use attributes vs. when to use properties in python?

Properties are more flexible than attributes, since you can define functions that describe what is supposed to happen when setting, getting or deleting them. If you don't need this additional flexibility, use attributes – they are easier to declare and faster.

In languages like Java, it is usually recommended to always write getters and setters, in order to have the option to replace these functions with more complex versions in the future. This is not necessary in Python, since the client code syntax to access attributes and properties is the same, so you can always choose to use properties later on, without breaking backwards compatibilty.

PHP classes - is it preferable to use normal variables instead of properties?

It's somewhat vague what you're asking, but if valueToUseHere is not used outside of doStuff, then don't make it a property!

class someClass {

    public function doStuff() {
        $valueToUseHere = 60;
        // Do more stuff here...
    }

}

If there's no reason to share that value with other methods of the class or with the outside world, then there's no reason to clutter up your object with all sorts of properties. Not only may this cause tricky bugs with preserved state, it also forces you to be unnecessarily careful with your variable names across all object methods.

When to Use Properties Instead of Functions