One of my collegues argues with me NOT to write the properties just declare instance variables as public...but in my last 4+ years of .net programming I always expose properties and do programming and i thought that is the good programming practice....what
is your opinion???
If you need to make a public variable a property, by all means do so.
If you don't need to make a public variable a property:
<div mce_keep="true"> Don't do it, you are just cluttering up the code.</div>
<div mce_keep="true"> Do it, then you can change the internal storage type at a later date without changing the interface.</div>
To me, having uncluttered code is more beneficial. In the unlikely event you are changing the internal storage type, you are probably making other significant changes...you may have to change the property type anyway. (I've heard this argment several times
but I've never seen it actually used).
AFAIK the reccomendation in .Net has always been to wrap fields in properties. The performance hit from a property is virtually non-existant. It allows you to easily put controls around who can set values. Many ORM systems and reflection-based frameworkds
do not work well with Fields. The only real argument against it I can see is that its more code.
If the answer I provided is useful or informative please check the "answer" button.
Warning: Code is often uncompiled and possibly started life written on the back of a napkin. Beware typos.
I am going to use reflections to read the property names and assign the database values to it...
even i heard on msdn that writing properties is a good programming practice thats why i am following it....but the argument it is happening is more lines of code but for me that is not more lines of code...since we have short -cut which will create the property
and only we need to play with set accessors...
here...i am creating a business object ....thats why i am concerned that i should expose properties only....if this has been on a .aspx file, then i would have played with instance variables by making them public but when i am creating a business object
which will be used by other people, then i thought exposing properties only would make some sense which holds with OOPs concenpt of data hiding or data excapsulation...
They don't just link to an underlying field. Additional processing (including validation), or not having a simple field become easy.
Get and set can have different accessibility, this can be significant if exposing a collection (can prevent client's from completely replacing the collection object by assigning the property).
You can put a breakpoint on a property.
Don't underestimate #3 when having problems with a non-trivial object graph.
As noted above, JIT inlining will mean simple properties have no real overhead, and then can easily have logic added without changing the class interface (changing a field to a property, or visa versa, does change with the interface). With automatic properties
it is now as easy to create a property as a field, so I really see no circumstances to use a public, non-static, field unless having to deal with a legacy fixed interface (including assumptions in reflection code).
Richard
Marked as answer by Figo Fei - MSFT on Sep 25, 2008 07:07 AM
Unless you have a very specific reason, the answer is very simple. Don't expose public fields. Use properties and methods as appropriate. Period.
There are lots of reasons why you should not expose public fields. Many, but not by far all, are listed in the previous answers.
Ask your collegue for a single reason why you should. "Less to type" is not a valid answer.
Svante
AxCrypt - Free Open Source File Encryption & Online Password Manager - http://www.axantum.com [Disclaimer: Code snippets usually uncompiled, beware typos.]
______
Don't forget to click "Mark as Answer" on the post(s) that helped you.
Marked as answer by Figo Fei - MSFT on Sep 25, 2008 07:07 AM
In addition to everything already said, properties are the only way your object can be used in .net controls such a gridview for example.
the .net framework uses reflection to find properties, you can't bind a column to a field.
Also, if you are using .net 3.5 there is no difference between using properties and field in amount of coding, that if the get and set accessors simply set/get the value from a field, obviously, if you need more complex logic you can't use fields.
Finally, I disagree with those who said the code is cleaner with fields, with a property somehow you encapsulate the value.
Today a property can simply expose the value of a field, tomorrow you might need a more complex logic for the same value, you would only need to change the get and set accessors of the property while if you used a field you will have to do a less clean
work.
If you use properties when you don't need them, you pay a price. And not just typing, I used the editor's refactor menu to create the 2nd class below:
// I prefer this...simple...clean
public class RedMachine
{
public bool Valve1_Open;
public bool Valve2_Open;
public bool Valve3_Open;
}
// I avoid this when I can
public class BlueMachine
{
private bool Valve1_Open;
public bool Valve1_Open1
{
get { return Valve1_Open; }
set { Valve1_Open = value; }
}
private bool Valve2_Open;
public bool Valve2_Open1
{
get { return Valve2_Open; }
set { Valve2_Open = value; }
}
private bool Valve3_Open;
public bool Valve3_Open1
{
get { return Valve3_Open; }
set { Valve3_Open = value; }
}
}
I guest 9 out of 10 properties are waste code. Almost of them are only set and get straight. I still use variable and i feel nothing disadvantage. Changing a instance variable to property is very easy.
Changing a instance variable to property is very easy.
Sure.
But what are you going to do about calling assemblies? Those that you have already deployed to one server or a million clients? Those that you did not even write yourself?
I do not consider it good practice to require recompilation and redeployment of all dependent assemblies, just because you need to change an exposed public field to a property. When the cost to avoid this problem is zero, zilch, nil.
It would be kind of interesting if the .NET framework was built using practices that required recompilation and recompilation of every single piece of .NET software on the planet, just because a software engineer at Microsoft required a public field to be
changed to a public property... Fortunately it is built using better practices than that.
This is just one of the many reasons why you should never expose public fields of a class, unless you have a very specific reason.
It's more likely to be ok if they are internal, protected or private (of course all reflection-based code will break if you change then). But this discussion is about public properties/fields.
Svante
AxCrypt - Free Open Source File Encryption & Online Password Manager - http://www.axantum.com [Disclaimer: Code snippets usually uncompiled, beware typos.]
______
Don't forget to click "Mark as Answer" on the post(s) that helped you.
diadem_2k
Member
272 Points
330 Posts
Importance of a property
Sep 23, 2008 01:26 PM|LINK
One of my collegues argues with me NOT to write the properties just declare instance variables as public...but in my last 4+ years of .net programming I always expose properties and do programming and i thought that is the good programming practice....what is your opinion???
SGWellens
All-Star
126031 Points
10310 Posts
Moderator
Re: Importance of a property
Sep 23, 2008 02:07 PM|LINK
If you need to make a public variable a property, by all means do so.
If you don't need to make a public variable a property:
To me, having uncluttered code is more beneficial. In the unlikely event you are changing the internal storage type, you are probably making other significant changes...you may have to change the property type anyway. (I've heard this argment several times but I've never seen it actually used).
My blog
JeffreyABeck...
All-Star
16423 Points
3329 Posts
Re: Importance of a property
Sep 23, 2008 02:18 PM|LINK
AFAIK the reccomendation in .Net has always been to wrap fields in properties. The performance hit from a property is virtually non-existant. It allows you to easily put controls around who can set values. Many ORM systems and reflection-based frameworkds do not work well with Fields. The only real argument against it I can see is that its more code.
Warning: Code is often uncompiled and possibly started life written on the back of a napkin. Beware typos.
diadem_2k
Member
272 Points
330 Posts
Re: Importance of a property
Sep 23, 2008 02:49 PM|LINK
I am going to use reflections to read the property names and assign the database values to it...
even i heard on msdn that writing properties is a good programming practice thats why i am following it....but the argument it is happening is more lines of code but for me that is not more lines of code...since we have short -cut which will create the property and only we need to play with set accessors...
here...i am creating a business object ....thats why i am concerned that i should expose properties only....if this has been on a .aspx file, then i would have played with instance variables by making them public but when i am creating a business object which will be used by other people, then i thought exposing properties only would make some sense which holds with OOPs concenpt of data hiding or data excapsulation...
thanks for giving some ideas....
rjcox
Contributor
7064 Points
1444 Posts
Re: Importance of a property
Sep 23, 2008 03:07 PM|LINK
Properties have three advantages over fields:
Don't underestimate #3 when having problems with a non-trivial object graph.
As noted above, JIT inlining will mean simple properties have no real overhead, and then can easily have logic added without changing the class interface (changing a field to a property, or visa versa, does change with the interface). With automatic properties it is now as easy to create a property as a field, so I really see no circumstances to use a public, non-static, field unless having to deal with a legacy fixed interface (including assumptions in reflection code).
Svante
All-Star
18347 Points
2300 Posts
Re: Importance of a property
Sep 23, 2008 03:36 PM|LINK
Unless you have a very specific reason, the answer is very simple. Don't expose public fields. Use properties and methods as appropriate. Period.
There are lots of reasons why you should not expose public fields. Many, but not by far all, are listed in the previous answers.
Ask your collegue for a single reason why you should. "Less to type" is not a valid answer.
AxCrypt - Free Open Source File Encryption & Online Password Manager - http://www.axantum.com
[Disclaimer: Code snippets usually uncompiled, beware typos.]
______
Don't forget to click "Mark as Answer" on the post(s) that helped you.
Ricardojb
Member
439 Points
144 Posts
Re: Importance of a property
Sep 23, 2008 07:57 PM|LINK
In addition to everything already said, properties are the only way your object can be used in .net controls such a gridview for example.
the .net framework uses reflection to find properties, you can't bind a column to a field.
Also, if you are using .net 3.5 there is no difference between using properties and field in amount of coding, that if the get and set accessors simply set/get the value from a field, obviously, if you need more complex logic you can't use fields.
Finally, I disagree with those who said the code is cleaner with fields, with a property somehow you encapsulate the value.
Today a property can simply expose the value of a field, tomorrow you might need a more complex logic for the same value, you would only need to change the get and set accessors of the property while if you used a field you will have to do a less clean work.
SGWellens
All-Star
126031 Points
10310 Posts
Moderator
Re: Importance of a property
Sep 24, 2008 01:39 AM|LINK
If you use properties when you don't need them, you pay a price. And not just typing, I used the editor's refactor menu to create the 2nd class below:
// I prefer this...simple...clean public class RedMachine { public bool Valve1_Open; public bool Valve2_Open; public bool Valve3_Open; } // I avoid this when I can public class BlueMachine { private bool Valve1_Open; public bool Valve1_Open1 { get { return Valve1_Open; } set { Valve1_Open = value; } } private bool Valve2_Open; public bool Valve2_Open1 { get { return Valve2_Open; } set { Valve2_Open = value; } } private bool Valve3_Open; public bool Valve3_Open1 { get { return Valve3_Open; } set { Valve3_Open = value; } } }My blog
Macolele
Member
320 Points
116 Posts
Re: Importance of a property
Sep 24, 2008 02:27 AM|LINK
I guest 9 out of 10 properties are waste code. Almost of them are only set and get straight. I still use variable and i feel nothing disadvantage. Changing a instance variable to property is very easy.
Svante
All-Star
18347 Points
2300 Posts
Re: Importance of a property
Sep 24, 2008 08:38 AM|LINK
Sure.
But what are you going to do about calling assemblies? Those that you have already deployed to one server or a million clients? Those that you did not even write yourself?
I do not consider it good practice to require recompilation and redeployment of all dependent assemblies, just because you need to change an exposed public field to a property. When the cost to avoid this problem is zero, zilch, nil.
It would be kind of interesting if the .NET framework was built using practices that required recompilation and recompilation of every single piece of .NET software on the planet, just because a software engineer at Microsoft required a public field to be changed to a public property... Fortunately it is built using better practices than that.
This is just one of the many reasons why you should never expose public fields of a class, unless you have a very specific reason.
It's more likely to be ok if they are internal, protected or private (of course all reflection-based code will break if you change then). But this discussion is about public properties/fields.
AxCrypt - Free Open Source File Encryption & Online Password Manager - http://www.axantum.com
[Disclaimer: Code snippets usually uncompiled, beware typos.]
______
Don't forget to click "Mark as Answer" on the post(s) that helped you.