469,610 Members | 2,511 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,610 developers. It's quick & easy.

Property or get/set methods ?

Hi,

I'm just wondering what are the guidelines for using a Property or a pair of
get/set methods related to a member variable ?
What do yu guys do ?

Thank you

Herve
Nov 16 '05 #1
8 6328

"Herve Bocuse" <gd******@gmail.com> wrote in message
news:cp**********@dns3.cae.ca...
Hi,

I'm just wondering what are the guidelines for using a Property or a pair
of
get/set methods related to a member variable ?
What do yu guys do ?


Never getX setX. Either properties or public member variables. I know many
people disagree, but I use public member variables alot on stuff that is not
visible across solutions. Public member variables should be named just like
properties, so if you later encapsulate the member variable, client code
won't break (although it will need to be recompiled). My rule of thumb for
public member variables is that they are OK instead of properties so long as
all the client classes get recompiled whenever the class containing the
member variable does.

I use initial-caps camel casing for all public data members, and
initial-lower camel casing for all private data members.

I also name constructor arguments after the public data member they
represent (possibly using this. in the constructor body to distinguish the
argument from the member).
class Foo1
{
public Foo1(int MyInt)
{
this.MyInt = MyInt;
}
public int MyInt;
}

or

class Foo2
{
public Foo2(int MyInt)
{
myInt = MyInt;
}
int myInt;
int MyInt
{
get
{
return myInt;
}
set
{
myInt = value;
}
}
}

David
Nov 16 '05 #2
> Public member variables should be named just like
properties, so if you later encapsulate the member variable, client code
won't break


For most cases, that is true; however, client code could still break -
fields can be passed ref/out while properties cannot.

Using fields instead of properties also changes the behavior of things like
the VS designer that uses GetProperties to populate the property grid.

There was another thread in this forum recently that went through a bunch of
these issues.
Nov 16 '05 #3
I wouldn't say that you should never GetX or SetX. If the setting or
getting of the property is a significant event (it would cause a long time
to execute, sets much more than just the value), then it is more appropriate
to have that in a method, then just a property.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:uM**************@TK2MSFTNGP11.phx.gbl...

"Herve Bocuse" <gd******@gmail.com> wrote in message
news:cp**********@dns3.cae.ca...
Hi,

I'm just wondering what are the guidelines for using a Property or a pair
of
get/set methods related to a member variable ?
What do yu guys do ?


Never getX setX. Either properties or public member variables. I know
many people disagree, but I use public member variables alot on stuff that
is not visible across solutions. Public member variables should be named
just like properties, so if you later encapsulate the member variable,
client code won't break (although it will need to be recompiled). My rule
of thumb for public member variables is that they are OK instead of
properties so long as all the client classes get recompiled whenever the
class containing the member variable does.

I use initial-caps camel casing for all public data members, and
initial-lower camel casing for all private data members.

I also name constructor arguments after the public data member they
represent (possibly using this. in the constructor body to distinguish the
argument from the member).
class Foo1
{
public Foo1(int MyInt)
{
this.MyInt = MyInt;
}
public int MyInt;
}

or

class Foo2
{
public Foo2(int MyInt)
{
myInt = MyInt;
}
int myInt;
int MyInt
{
get
{
return myInt;
}
set
{
myInt = value;
}
}
}

David

Nov 16 '05 #4
Also, if you have a case where you want to be able to set, but not get, then
personally I think a write-only property is weird and confusing, and I would
make that a set method.

-Rachel

"Nicholas Paldino [.NET/C# MVP]" <mv*@spam.guard.caspershouse.com> wrote in
message news:eD**************@tk2msftngp13.phx.gbl...
I wouldn't say that you should never GetX or SetX. If the setting or
getting of the property is a significant event (it would cause a long time
to execute, sets much more than just the value), then it is more
appropriate to have that in a method, then just a property.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"David Browne" <davidbaxterbrowne no potted me**@hotmail.com> wrote in
message news:uM**************@TK2MSFTNGP11.phx.gbl...

"Herve Bocuse" <gd******@gmail.com> wrote in message
news:cp**********@dns3.cae.ca...
Hi,

I'm just wondering what are the guidelines for using a Property or a
pair of
get/set methods related to a member variable ?
What do yu guys do ?


Never getX setX. Either properties or public member variables. I know
many people disagree, but I use public member variables alot on stuff
that is not visible across solutions. Public member variables should be
named just like properties, so if you later encapsulate the member
variable, client code won't break (although it will need to be
recompiled). My rule of thumb for public member variables is that they
are OK instead of properties so long as all the client classes get
recompiled whenever the class containing the member variable does.

I use initial-caps camel casing for all public data members, and
initial-lower camel casing for all private data members.

I also name constructor arguments after the public data member they
represent (possibly using this. in the constructor body to distinguish
the argument from the member).
class Foo1
{
public Foo1(int MyInt)
{
this.MyInt = MyInt;
}
public int MyInt;
}

or

class Foo2
{
public Foo2(int MyInt)
{
myInt = MyInt;
}
int myInt;
int MyInt
{
get
{
return myInt;
}
set
{
myInt = value;
}
}
}

David


Nov 16 '05 #5
I don't expose public class variables at all. It's a bad idea, and
breaks encapsulation. It's easy to take a ref from a public class
variable and turn it into something that it shouldn't be. Properties
make sure that your vars are yours.

Personally, I believe that exposing public variables is just a sign of
laziness.

As for getX/setX methods, it depends on your taste. Technically
speaking, the properties in C# and VB.NET are replaced by the compiler
with get/set methods. To me, it's just too java-ish, but then again, I
have no problem with write-only properties. :-P
Nov 16 '05 #6

"Mike Newton" <MN*****@discussions.microsoft.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
I don't expose public class variables at all. It's a bad idea, and breaks
encapsulation. It's easy to take a ref from a public class variable and
turn it into something that it shouldn't be. Properties make sure that
your vars are yours.

Personally, I believe that exposing public variables is just a sign of
laziness.


Yes. I am lazy. And I agree that exposing public variables is just a sign
of laziness.

But laziness in programming is a vice in inverse proportion to the type
safety of the language.

For POD types, private types, and "friend" types, the cost of variable
encapsulation is not always worth the effort.

David
Nov 16 '05 #7

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:uG**************@TK2MSFTNGP09.phx.gbl...
Also, if you have a case where you want to be able to set, but not get,
then personally I think a write-only property is weird and confusing, and
I would make that a set method.


Agree on both. Properties should only be used as a replacement for a
getter, or a getter/setter pair, where the methods are:
-Not resource intensive
-The getter does not change the state of the object in any visible way
-The setter does not change the visible state of the object, except for the
value returned by the getter.
I don't like properties at all where you have to set PropertyX before you
can run MethodY. This should be a constructor argument or an argument to
MethodY.

David
Nov 16 '05 #8
A property should be used when a value is likely to change over a long
period of time. For instance, Rate Of Interest. It should be used when
your class depends upon an user input again for instance, the account
class which may depend upon the rate of interest supplied by the user
and hence, you should take it into a property.

with regards,
J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

11 posts views Thread by Laszlo Zsolt Nagy | last post: by
18 posts views Thread by Robin Becker | last post: by
15 posts views Thread by Prachi Dimble | last post: by
13 posts views Thread by Peter Kirk | last post: by
6 posts views Thread by David Hearn | last post: by
14 posts views Thread by Dom | last post: by
2 posts views Thread by =?Utf-8?B?Z2FkeWE=?= | last post: by
reply views Thread by devrayhaan | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.