Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When to use properties instead of functions

This is probably a matter of personal preference, but when do you use properties instead of functions in your code

For instance to get an error log I could say

string GetErrorLog() {       return m_ErrorLog; } 

or I could

string ErrorLog {      get { return m_ErrorLog; } } 

How do you decide which one to use? I seem to be inconsistent in my usage and I'm looking for a good general rule of thumb. Thanks.

like image 314
Steve Avatar asked Sep 03 '09 15:09

Steve


People also ask

What is the difference between properties and functions?

The main purpose of the property is to allow class to expose its private variables and representing the data portion of the class, function representing the actions. In the following example, RotbotName() is a property, it representing a conception thing, a data member. VerifyName() is a function.

Why we are using properties?

Properties are special kind of class member, In Properties we use predefined Set or Get method. They use accessors through which we can read, written or change the values of the private fields. For example, let us Take a class named Employee, with private fields for name,age and Employee Id.

Why are properties better than fields?

Properties can be used to read only or write only other fields. This could be done by declaring only either get{} or set{}. Also they can have access modifiers, like private, so you can only get or set their values inside their class.

What is the difference between property and method in C#?

Ans: A property is a named attribute of an object. Properties define the characteristics of an object such as Size, Color etc. or sometimes the way in which it behaves. A method is an action that can be performed on objects.


2 Answers

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.
like image 117
Reed Copsey Avatar answered Sep 30 '22 03:09

Reed Copsey


Here are Microsoft's guidelines:

Choosing Between Properties and Methods

  • Consider using a property if the member represents a logical attribute of the type.

  • Do use a property, rather than a method, if the value of the property is stored in the process memory and the property would just provide access to the value.

  • Do use a method, rather than a property, in the following situations.

    • The operation is orders of magnitude slower than a field set would be. If you are even considering providing an asynchronous version of an operation to avoid blocking the thread, it is very likely that the operation is too expensive to be a property. In particular, operations that access the network or the file system (other than once for initialization) should most likely be methods, not properties.

    • The operation is a conversion, such as the Object.ToString method.

    • The operation returns a different result each time it is called, even if the parameters do not change. For example, the NewGuid method returns a different value each time it is called.

    • The operation has a significant and observable side effect. Note that populating an internal cache is not generally considered an observable side effect.

    • The operation returns a copy of an internal state (this does not include copies of value type objects returned on the stack).

    • The operation returns an array.

like image 21
Ryan Lundy Avatar answered Sep 30 '22 04:09

Ryan Lundy