Method vs Property in C# - what's the difference

Question

Possible Duplicate:
Properties vs Methods

In method you can type some code and in properties too. For example I have a property Name. When class name changes I would like to get some data from database and change state of my object. I can add this code to set part of my property. Other solution is to change set part to private and add method called SetName and in this method add my code.

So what is the difference? When is the point when it's not good to put some code to getter / setter and when to create own method that is used to change my property and other parts of my class?

Answer 1

Given a property like this

private string _name;
public string Name { get { return _name; } set { _name = value; } }

it is possible to write the following two methods:

public string get_Name() { return _name; }
public void set_Name(string value) { _name = value; }

which act identically. And in fact, this is exactly what the compiler does for you when you create a property.

Generally speaking, I steer away from properties when the code within them starts to feel "expensive", if that makes any sense. I want properties to feel like fields (with controlled side effects that happen at specific times), so they should be lightweight.

Answer 2

A property is nothing but some syntactic sugar. In some cases, it is better to define a property instead of a method because it is clearer / more readable.

Design guidelines state that, when the functionality you're implementing is expensive, a method should be preferred over a property.

in fact, a property is implemented as one or two methods; depending whether your property has a setter or not. The property is translated into a get_xxx and a set_xxx method.

Answer 3

Whenever I've come across the need to put code in a getter/setter I put the code in a private method and call that method from within the getter/setter. That way the code is available in a method call should I need it elsewhere. Not sure if this is the answer you were seeking but it is just a methodology I use.

Answer 4

Essentially a property is a couple of methods - getProperty and setProperty. It is only the convention / simplification of the thing.

It is assumed that property getter has no side effects (well - they might have certain side effect, like lazy loading).

Answer 5

Methods do something. Which is why typically they are have Verbs in there names.

While property returns data.

The line is simple, a property should become a method if it is do something other than accessing the class internal data stores.

For example if you are a Property called NumberOfQuetions for a users. If it has to go to the database to get the number of questions that should be a method. If it is returning an internal store, even if some logic is done on the internal store you can keep that in the get.

Answer 6

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.

Answer 7

This probably isn't the most important difference, but one of the differences is that the debugger can be configured to step over properties (assuming their code is trivial).

Answer 8

There is basically no difference (except for the reserved identifier "value" in a setter).

Getters and setters get internally translated into standard methods such that the runtime has no idea whether some getter or setter is associated with a certain property. The term syntactic sugar is often used for convenience constructs like these.

However, there is an important software engineering benefit: your code tends to be easier to understand if you restrict yourself to use getters and setters with get and set semantics. I.e. do only the steps necessary to provide the respective property.

A common use case for doing a bit of extra work is for instance the setting or getting of a property which is not directly backed by a member field. For example, you've got a class that contains say a value that represents a distance. Your class could provide two Properties: Kilometers and Miles with respective setters and getters. Then you would do simple conversions in one pair and save yourself to store the value twice.

As a general rule of thumb, you should not put any code in a getter that has side effects. Also, the only side effect that code in a setter should have is the change of state in the object the setter refers to.

Answer 9

Coming to think of it, Properties are more than just syntactic sugar. They are the public face of your member data to you member code.

Thus, giving you a clean layer for retrieval or input of a single aspect of you member data from you code.

A DTO for example is nothing but a bunch of well written properties, cleaving data and behavior efficiently. Without a DTO would you imagine tightly coupling your DataGrid or Dropdown to complex business logic method?

Put it simply, Methods are actually doing the work...Properties either instigate action or get the status.

Though, you can use method code inside your properties ...it is not what they are meant for. Even, if you have to you are better of making a clean call to another method inside the property instead of actually writing you code in it. HTH!