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 ?
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?
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.
Properties holds object data
Functions defines object behavior
Take a look at -> Property Usage Guidelines
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.
I'm a little late to this party, but I'll just mention another surprising difference between a property and a parameterless "get" method. As @MarcGravell notes, lazy loading is a common pattern when using properties, but beware of the Heisenberg Watch Window gotcha!
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.
Property is a way explore the internal data element of a class in a simple manner. We can implement a properties with the type-safe get and set method.Property is implicitly called using calling convention.Property works on compile and runtime.
Method is a block of code that contain a series of statements.Method is explicitly called. Methods works on runtime.
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.
