views:

273

answers:

6

Which one is better to use when it come to return value for example

public int EmployeeAge
{
    get{return intEmployeeAge};
}

And

public int EmployeeAge()
{
    return intEmployeeAge;
}

Which one is better and why? And what is best programming practice to use when we have secnario like above ?

+1  A: 

A method returns values after work is completed and a value is the result of the work being done. I don't think this is what you are doing.

A property (accessor) is meant for returning variables, which seems to be what you're trying to achieve:

As per MSDN:

The accessor of a property contains the executable statements associated with getting (reading or computing) or setting (writing) the property. The accessor declarations can contain a get accessor, a set accessor, or both. The declarations take the following forms:

public int EmployeeAge
{
    get;
    set;
}

Have a look here, as it gives a very good description on the uses of these.

Kyle Rozendo
A: 

I think this has a lot to do with the culture you are programming in. As I see it, the C# / .NET culture would prefer to use a property for this case.

My advice: Try to be consistent with the main libraries you are using.

BUT: Be wary of using properties (or functions that serve the same purpose, as in your example above), as they are often a sign of bad design. You want to tell your objects to do stuff, as opposed to asking them for information. Don't be religious about this, though, just be aware of this as a code smell.

Daren Thomas
Culture? didn't get your point, as In both cases it onlye return employee age.
Asim Sajjad
By *culture* I mean the body of code that comes with a language / platform, the community of developers using them and the libraries they create.
Daren Thomas
I don't understand your code smell reference. A complicated object might have many properties especially if it has multiple ancestors...
Dining Philanderer
@Dining Philanderer: Sure it can. But be wary of such objects. Make sure you are certain that it needs to be what it is, since having lots of properties could be a sign of bad design. Properties tend to create dependencies and complicated if/else code.
Daren Thomas
+2  A: 

If all you need to do is return a value, use a property.

If you need to do something before returning a value, use a function.

Oded
But in case of property I can also add some processing what you call it "do something" before return value in property as well, in above case both are returning value. but which is better ?
Asim Sajjad
Yes, you can, but you need to think about _meaning_. Most programmers, when calling a property do not expect it to change object state, but when calling a function they do expect this.
Oded
+13  A: 

Properties are a useful way of expressing a feature of an object, allowing get/set in a common way that can be used by APIs like data-binding, reflection and serialization. So for simple values of the object, properties are handy. Properties can't take arguments, should not have significant side-effects*, and should return quickly and repeatably. Also, there is no such thing as an "extension property" (to mirror an extension method) nor a generic property.

(*=lazy loading etc isn't uncommon, however)

Methods (C# doesn't have functions) are better for expressing things that either change the state, or which have an expectation of taking some time and not necessarily being reproducible. They don't tend to work in binding / serialization etc.

Note that properties are actually just a special way of writing methods. There is little functional difference. It is all about expressing intent. The one thing you don't want to expose, however, is fields (the actual intEmployeeAge instance variable).

So I would have:

public int EmployeeAge { get{return intEmployeeAge}; }

or just (if on the Employee object):

public int Age { get{return intEmployeeAge}; }

Of course... then the question becomes "in what unit?" I assume that is years?

Marc Gravell
good answer....
Morten Anderson
/agreed.In a simple way, properties are designed to expose private fields outside the class to ensure no breaking changes if the class architecture is revised.
JoeBilly
@JoeBilly - well, you can do a *bit* more than that without it getting too messy. But simple is as simple does, so they say.
Marc Gravell
@Marc - Sure it was popularized. I mean you can do a lot of thing with a proeprty (good or bad) but it is an accessor first.
JoeBilly
+2  A: 

Properties holds object data

Functions defines object behavior

Take a look at -> Property Usage Guidelines

Morten Anderson
A: 

Which one is better and why? And what is best programming practice to use when we have secnario like above ?

I write in C# however I prefer to use Get/Set functions, for me it's just better way to express what I can get from object and how I can change it's state (and this methods are grouped by alphabet in Intelisense which is also nice). However, if team prefers other conventions it's not a problem but when I work on my own projects it's just easier to read API.

e.g

Obejct1 o = new Object1();
o.P1;
o.P2;
o.P3;

from looking to API you can't say what you change in a public API or what it a read only property, unless you use IDE that shows you a small icon showing actually what you can do.

Object1 o = new Object1();
o.GetP1();
o.SetP2();
o.SetP3();

One can easily find from API how data can be changed by type's clients.

Andrei Taptunov