Property or get/set methods ?

[Herve Bocuse]

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

[David Browne]

"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

[MarkT]

> 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.

[Nicholas Paldino [.NET/C# MVP]]

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

[Rachel Suddeth]

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

[Mike Newton]

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

[David Browne]

"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

[David Browne]

"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

[Ravichandran J.V.]

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!