Use of properties

[Paul Mcilreavy]

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to cause
me concern. Any comments or other viewpoints is appreciated.

[Marina Levit [MVP]]

I think that really depends on the object in question, I don't know if it's
fair to make absolute rules.

Yes, generally properties just return values of private members. But if
that is all they ever did, there really wouldn't be much of a point to them,
would there? There are instances where a property must do some validation,
or some other processing in order to keep the object in a consistent state
given that the value of this property is being changed.

Sometimes a property needs to point to another big object, just because the
two objects are linked together and they need to talk to each other.

It's really hard to say one way or the other for a vague non specific
situation. I'm sure any construct can be misused, but in the end it all
really depends on the application and the objects involved as to what is
appropriate. At least that's my 2 cents.

"Paul Mcilreavy" <fa********@discussions.microsoft.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

[Peter Duniho]

"Paul Mcilreavy" <fa********@discussions.microsoft.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

Well, this is bound to vary somewhat from person to person, since there are
no hard and fast rules. But my opinion as to the proper use of properties
is generally this:

* Properties are used when they can return something that is
semantically a characteristic of the object, whether static (doesn't change
during the lifetime of the object) or dynamic (may in fact change during the
lifetime of the object). If you can think of a value as somehow being tied
to the object itself, then it can be implemented as a property.

* Methods are used when one is specifically asking an object to *do*
something. This may involve returning some value, just as a property does,
or it may not. The key is that the method is used when the important thing
is the *doing*, as opposed to the *being* that a property describes.

To me, properties are nouns and adjectives related to the class, while
methods are the verbs of the class.

Note that in neither of those descriptions is there any mention of how much
effort it takes to accomplish one or the other. I would agree that
generally speaking, a property should be relatively lightweight, especially
with respect to execution time. But I don't feel this is a hard-and-fast
rule (and besides, it could also be argued that most methods should also be
relatively lightweight, especially with respect to execution time).

If semantically it makes sense for something that takes a fair amount of
work to retrieve before returning it to the caller or before changing the
state of an object (remember that properties can be retrieved, set, or both)
to still be considered a property, I think the semantics should overrule the
performance issues. After all, if you have some amount of work to be done,
it's the same whether you call it a method or a property. Imposing
artificial, implementation-related restrictions on what is essentially a
semantic question is wrong, IMHO.

As far as the question of the size of an object being returned, IMHO that's
a complete non-issue. If semantically it makes sense for a very large
object to be returned by a property, then so be it. Return it from a
property. The size of the data has nothing to do with whether something
should be a property or a method. Some methods may return a single integer
value, while some properties may return an array with tens of thousands of
elements.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

You should be concerned if properties are being used for literally
*everything*. But not for the reasons you suggest.

Pete

[Martijn Mulder]

Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member, data,
functions (methods) and now, NEW NEW NEW, properties. My experience is, when
I want to get some value, I use Get...(), when I want to set something, I
use Set...(value); Then you know where to look for what happens.

[fallenidol]

yep, they would need to do some validation etc on occaision. i guess i meant
that if a property is over 10-20 lines...doing alot of validation or dealing
with big obects that can generate errors...then it should probably be a
method rather than a property
"Marina Levit [MVP]" <so*****@nospam.comwrote in message
news:ug*************@TK2MSFTNGP04.phx.gbl...

>I think that really depends on the object in question, I don't know if it's
fair to make absolute rules.

Yes, generally properties just return values of private members. But if
that is all they ever did, there really wouldn't be much of a point to
them, would there? There are instances where a property must do some
validation, or some other processing in order to keep the object in a
consistent state given that the value of this property is being changed.

Sometimes a property needs to point to another big object, just because
the two objects are linked together and they need to talk to each other.

It's really hard to say one way or the other for a vague non specific
situation. I'm sure any construct can be misused, but in the end it all
really depends on the application and the objects involved as to what is
appropriate. At least that's my 2 cents.

"Paul Mcilreavy" <fa********@discussions.microsoft.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

>Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

[Larry Smith]

Hi, i would like to get some view points on the use of properties within

classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

While it may be a religious issue, I for one strongly agree with you. It
seems likely that the language's authors even intended it this way. They
should usually provide fast, efficient and reliable access. It's cleaner and
really reflects their intended usage. Moreover, I think most people usually
assume this so if a property isn't efficient and people are frequently
calling it (perhaps in tight loops), then it can potentially have a negative
impact on your app's performance. Finally, as a purely practical issue, see
the following two links (by MSFT employees). I've experienced frustrating
problems with these issues and was personally told by a member of the VS
debugging team (Azeem Khan) that simple properties (returning member
variables only) can significantly help to avoid these problems.

http://blogs.msdn.com/greggm/archive...18/494648.aspx
http://blogs.msdn.com/greggm/archive.../04/67766.aspx

[Göran Andersson]

Martijn Mulder wrote:

>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member, data,
functions (methods) and now, NEW NEW NEW, properties. My experience is, when
I want to get some value, I use Get...(), when I want to set something, I
use Set...(value); Then you know where to look for what happens.

It seams that you totally missed the entire concept of object orientation.

[sloan]

I use "derived" properties at time.

Think about the age of a person. It is based on today's date , and hte dob
(date of birth ) of a person.

So ... I'll expose a "derived" property, usually readonly.

public int AgeInYears
{
get
{
return this.DeterimineAgeInYears();
}
}

private int DeterimineAgeInYears
{
if (this.m_dob != DateTime.MinDate )
{
return DateTime.Now.Substract( this.m_dob ).Years;
}
else
{
// throw new Exception("DOB was not supplied"); //<- throw an exception?
I usually don't. But its an option.
return 0;
}
}
Something along those lines.
Should I just expose the private method DeterimineAgeInYears ? Maybe? It
just depends I guess.
Sometimes I have the ".Status" property where I need to check 3 or 4 things.
But there's some food for thought. When its a "derived" property, then I do
more than just return a member variable.
At the same time, 99.8% of the time, returning a member variable is all I
do.


"Paul Mcilreavy" <fa********@discussions.microsoft.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to

cause

me concern. Any comments or other viewpoints is appreciated.

[Bill Butler]

"Martijn Mulder" <i@mwrote in message
news:45***********************@news.wanadoo.nl...

>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact
they obscure your code. Suddenly there is a third kind of class
member, data, functions (methods) and now, NEW NEW NEW, properties. My
experience is, when I want to get some value, I use Get...(), when I
want to set something, I use Set...(value); Then you know where to
look for what happens.

If you don't like properties, perhaps you should program in another
language.
Properties are an integral part of C#.

Bill

[Martijn Mulder]

>>Hi, i would like to get some view points on the use of properties

>Properties are best avoided. They seem great at first, but...

It seams that you totally missed the entire concept of object orientation.

Totally... entire. Wow. Properties are just another way of implementing
Set...(value) and Get...() methods. In fact, the compiler substitutes
properties with methods with that signature. Totally and entire

[Bob Jones]

On 2006-10-24 15:54:18 -0500, Göran Andersson <gu***@guffa.comsaid:

Martijn Mulder wrote:

>>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member,
data, functions (methods) and now, NEW NEW NEW, properties. My
experience is, when I want to get some value, I use Get...(), when I
want to set something, I use Set...(value); Then you know where to look
for what happens.

It seams that you totally missed the entire concept of object orientation.

".. totally missed the entire concept of [OO]". Not. "Properties" a-la
MS Csharp (a.k.a. "not Java") is an implementation supporting the
concepts of encapsulation and information hiding - which are OO
concepts.

I agree that properties can "obscure" the code, but I do not agree that
they are "best avoided." Seems to me they are a somewhat cutesy
"we-gotta-be-different" Microsoft thing that I first saw as part of
Visual Basic's back then "kinda-sorta OO implementation" a few years
ago. Now that MS seems to be making all .NET languages exactly the
same, but different (?!) C sharp gets properties.

Yeah, they're just odd (to Java, C++, etc. programmers) "getters and
setters", and the way we tend to use them - an Uppercase spelling
(Pascal Case) of a private field, they do tend to be confusing at
times. Nonetheless I kinda like the clean synax of it.

I do think they're over-used. There really is no point in making a
field private and supplying a Property when you really want a public
field. Make the field public, duh. There is no rule that says all
fields (aka instance variables) must not be public. OTOH I think if
you have a derived value - that takes some kakulatin' - then a Property
is a neat way to make the code look like you're referencing a public
field.

[Peter Duniho]

"Bob Jones" <ro****@joneshouse.comwrote in message
news:2006102422000350073%robert@joneshousecom...

[...]
I agree that properties can "obscure" the code, but I do not agree that
they are "best avoided." Seems to me they are a somewhat cutesy
"we-gotta-be-different" Microsoft thing that I first saw as part of
Visual Basic's back then "kinda-sorta OO implementation" a few years ago.

For the record, VB had properties as far back as the early 90's. Not that
that's all that relevant, just thought I'd mention it. :)

[...]
I do think they're over-used. There really is no point in making a field
private and supplying a Property when you really want a public field. Make
the field public, duh.

This I disagree with wholeheartedly. One key feature of encapsulating a
field is that you control access to it. You can do range checking, and you
have the ability to in the future add logic that does other work in response
to the field changing. You can even change the underlying implementation of
the property if you like without breaking clients of the class. None of
this is possible if the field is simply a public field.

IMHO, there is no reason at all to ever make a field public. That's for
structures, not classes.

Pete

[Jon Skeet [C# MVP]]

Martijn Mulder <i@mwrote:

Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member, data,
functions (methods) and now, NEW NEW NEW, properties. My experience is, when
I want to get some value, I use Get...(), when I want to set something, I
use Set...(value); Then you know where to look for what happens.

Given that you should practically never be exposing fields anyway, I
don't see there's any significant difference - anything you can do with
an object *may* be doing work.

The difference is in readability - it's a lot easier to read code using
properties than setters and getters. Oh, and using your own classes
looks a lot more like using the framework classes as well, given that
they use properties extensively.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Bob Jones <ro****@joneshouse.comwrote:

<snip>

I do think they're over-used. There really is no point in making a
field private and supplying a Property when you really want a public
field. Make the field public, duh. There is no rule that says all
fields (aka instance variables) must not be public. OTOH I think if
you have a derived value - that takes some kakulatin' - then a Property
is a neat way to make the code look like you're referencing a public
field.

Well, there are certainly *plenty* of "guidelines" saying not to make
fields public, and plenty of reasons not to. Using fields instead of
properties:

1) You can't do validation
2) You can't *easily* break on all access/modification
3) You can't make a field read-only for everything outside the class
4) You can't change the implementation of how that essential
characteristic of the class is represented internally

Basically, it's a leaky abstraction. Too much of the implementation is
visible.

Once you've made something a field, you can't turn it into a property
without losing both source and binary compatibility. Maybe you don't
care about that, but a lot of people do.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

fallenidol <fa********@discussions.microsoft.comwrote:

yep, they would need to do some validation etc on occaision. i guess i meant
that if a property is over 10-20 lines...doing alot of validation or dealing
with big obects that can generate errors...then it should probably be a
method rather than a property

Doing a lot of validation? Not a problem, IMO.
Dealing with big objects? Not a problem, IMO.
Possibly generating errors? Not a problem, IMO - so long as it's
documented.

There's a vague expectation that property access should usually be
"pretty fast", and properties should usually be orthogonal (so changing
one property shouldn't usually change another - unless one is read-only
and solely calculated from others, eg Area from Width and Height).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Marc Gravell]

There is no rule that says all fields (aka instance variables) must not be public.

There is to me. Or at least a very very strong suggestion not to
*until* given a good reason. Note: I have only ever found a good enough
reason twice since working with C#...

Validation
Interface implementation (interfaces can't declare fields)
Synchronisation (where needed only; not by default)
Change notification (for binding etc, or just the component model)
Consistent approach re the component model / adding a virtual (runtime)
property

But most importantly: Encapsulation: the ability to both hide and
change the implementation... if you write software that is going to be
in rolling development for a period of time with multiple developers
building on it, then you need to be able to change the internals
without affecting the contract - for instance, switching to a facade,
or moving fields into / out-of a property bag, things like that. You
can't do this with fields, and you can't rely on just switchin the
field to a property, as this is a breaking change. Even if you rebuild
the callers, "ref" usage won't work.

Marc

[KH]

Peter, I've seen you at least once before use the analogy of properties as
adjectives and methods as verbs, and I think it's about as correct a
description to differentiate the two as possible.

A class represents a thing, a noun, and methods act on the object making
them verbs - the thing performs an action. The semantic problem with methods
as property accessors is that (in the real world) an object doesn't perform
an action to show a property of itself, e.g. a dog can perform the action of
running, but does not perform any action to show you its color. So a method
like GetColor() implies an action which doesn't really occur for a descriptor
(adjective).

Of course I'm indulging some sort of programming nirvana where types always
represent real-world things, and there aren't other factors like an
expectation of properties not performing too much(1) work, which I also agree
with, but nonetheless it's a good idiom for ideal use of properties vs.
methods.

- Ken

(1) "too much": loosley defined as "more than I think it should" ;)

"Peter Duniho" wrote:

"Paul Mcilreavy" <fa********@discussions.microsoft.comwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

Well, this is bound to vary somewhat from person to person, since there are
no hard and fast rules. But my opinion as to the proper use of properties
is generally this:

* Properties are used when they can return something that is
semantically a characteristic of the object, whether static (doesn't change
during the lifetime of the object) or dynamic (may in fact change during the
lifetime of the object). If you can think of a value as somehow being tied
to the object itself, then it can be implemented as a property.

* Methods are used when one is specifically asking an object to *do*
something. This may involve returning some value, just as a property does,
or it may not. The key is that the method is used when the important thing
is the *doing*, as opposed to the *being* that a property describes.

To me, properties are nouns and adjectives related to the class, while
methods are the verbs of the class.

Note that in neither of those descriptions is there any mention of how much
effort it takes to accomplish one or the other. I would agree that
generally speaking, a property should be relatively lightweight, especially
with respect to execution time. But I don't feel this is a hard-and-fast
rule (and besides, it could also be argued that most methods should also be
relatively lightweight, especially with respect to execution time).

If semantically it makes sense for something that takes a fair amount of
work to retrieve before returning it to the caller or before changing the
state of an object (remember that properties can be retrieved, set, or both)
to still be considered a property, I think the semantics should overrule the
performance issues. After all, if you have some amount of work to be done,
it's the same whether you call it a method or a property. Imposing
artificial, implementation-related restrictions on what is essentially a
semantic question is wrong, IMHO.

As far as the question of the size of an object being returned, IMHO that's
a complete non-issue. If semantically it makes sense for a very large
object to be returned by a property, then so be it. Return it from a
property. The size of the data has nothing to do with whether something
should be a property or a method. Some methods may return a single integer
value, while some properties may return an array with tens of thousands of
elements.

My company seems to be using them for everything which is starting to
cause me concern. Any comments or other viewpoints is appreciated.

You should be concerned if properties are being used for literally
*everything*. But not for the reasons you suggest.

Pete

[Martijn Mulder]

The difference is in readability - it's a lot easier to read code using

properties than setters and getters. Oh, and using your own classes
looks a lot more like using the framework classes as well, given that
they use properties extensively.

Using properties is not a problem and indeed it looks rather neat. Writing
and maintaining your own properties does give some headache. Where, for
example, do you store them in the source file? I put fields at top, then the
constructor(s) followed by the methods, in alphabetical order. Properties
landed between the fields and the constructor, were hard to find, were hard
to maintain. It's a hybrid data type invented only to please the eye.

[Jon Skeet [C# MVP]]

Martijn Mulder <i@mwrote:

The difference is in readability - it's a lot easier to read code using
properties than setters and getters. Oh, and using your own classes
looks a lot more like using the framework classes as well, given that
they use properties extensively.

Using properties is not a problem and indeed it looks rather neat. Writing
and maintaining your own properties does give some headache. Where, for
example, do you store them in the source file? I put fields at top, then the
constructor(s) followed by the methods, in alphabetical order. Properties
landed between the fields and the constructor, were hard to find, were hard
to maintain. It's a hybrid data type invented only to please the eye.

Well, I put them between the constructors and the other methods -
although I group methods by use rather than alphabetically.

I don't think it's a significant headache compared with the increase in
readability though.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[ssamuel]

Paul,

The only "general rule" I've ever heard was that a get property should
not change the state of an object.

A corollary would be that the set should probably only change the one
"thing" that the property refers to, although this isn't always only
one member variable.

For instance, if you have a Car object, and it's got a private Color
member variable, that's a property. Get should pretty much return the
value in the member variable, and set may do some value-add things like
make sure it's not null and check to see it's a valid color. Set
probably shouldn't change your BodyFrameType even though the
4By4Extended version isn't available in Green. Rather, it should set a
flag InvalidOptionCombination and wait for ResetValidValues(), which
will decide that 4By4Extended trumps Green and Color should be set back
to Red.

On the other hand, if you have a RecordSet object that contains a
private pointer to the current record, and there's a Read that gives
you the current record then moves the pointer to the next, Read should
be a method. By calling it, you're changing the state of the RecordSet,
so it shouldn't be a property. In this case, it also makes little sense
to have a Read property, because the whole concept of "set Read"
doesn't even make sense.

As far as performance, people generally expect properties to return
quickly. "Quickly" is purely relative: if you're reading 12GB
object-relational data structures from an Internet-distributed data
source, "lightning quick" could mean a few hours. This comes into play
most in multi-threaded scenarios: users probably want to hold a
pessimistic lock on your object while they use the property then act on
the information. If this causes them to hold a lock for a long time or
causes a deadlock, users will be unhappy.

I've also seen some peoples' coding preferences that use no properties.
These people usually wrote a lot of Java or C++ before C#. It's valid
but outdated.
Stephan

Paul Mcilreavy wrote:

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to cause
me concern. Any comments or other viewpoints is appreciated.

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>
Well, there are certainly *plenty* of "guidelines" saying not to make
fields public, and plenty of reasons not to. Using fields instead of
properties:

1) You can't do validation
2) You can't *easily* break on all access/modification
3) You can't make a field read-only for everything outside the class
4) You can't change the implementation of how that essential
characteristic of the class is represented internally

If you need to do any of that, then of course you must use properties.
That's a no-brainer.

Otherwise, I don't see the point in writing both getters and setters instead
of making fields public. I think both approaches represent code smells, but
that the latter is more intention-revealing and less messy than the latter.
It's also more agile, in not writing code that's not needed.

///ark

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@communitymtm.comwrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

Well, there are certainly *plenty* of "guidelines" saying not to make
fields public, and plenty of reasons not to. Using fields instead of
properties:

1) You can't do validation
2) You can't *easily* break on all access/modification
3) You can't make a field read-only for everything outside the class
4) You can't change the implementation of how that essential
characteristic of the class is represented internally

If you need to do any of that, then of course you must use properties.
That's a no-brainer.

Otherwise, I don't see the point in writing both getters and setters instead
of making fields public. I think both approaches represent code smells, but
that the latter is more intention-revealing and less messy than the latter.
It's also more agile, in not writing code that's not needed.

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Göran Andersson]

What post are you trying to reply to, really?

Bob Jones wrote:

On 2006-10-24 15:54:18 -0500, Göran Andersson <gu***@guffa.comsaid:

>Martijn Mulder wrote:

>>>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact
they obscure your code. Suddenly there is a third kind of class
member, data, functions (methods) and now, NEW NEW NEW, properties.
My experience is, when I want to get some value, I use Get...(), when
I want to set something, I use Set...(value); Then you know where to
look for what happens.

It seams that you totally missed the entire concept of object
orientation.

".. totally missed the entire concept of [OO]". Not. "Properties" a-la
MS Csharp (a.k.a. "not Java") is an implementation supporting the
concepts of encapsulation and information hiding - which are OO concepts.

I agree that properties can "obscure" the code, but I do not agree that
they are "best avoided." Seems to me they are a somewhat cutesy
"we-gotta-be-different" Microsoft thing that I first saw as part of
Visual Basic's back then "kinda-sorta OO implementation" a few years
ago. Now that MS seems to be making all .NET languages exactly the same,
but different (?!) C sharp gets properties.

Yeah, they're just odd (to Java, C++, etc. programmers) "getters and
setters", and the way we tend to use them - an Uppercase spelling
(Pascal Case) of a private field, they do tend to be confusing at times.
Nonetheless I kinda like the clean synax of it.

I do think they're over-used. There really is no point in making a field
private and supplying a Property when you really want a public field.
Make the field public, duh. There is no rule that says all fields (aka
instance variables) must not be public. OTOH I think if you have a
derived value - that takes some kakulatin' - then a Property is a neat
way to make the code look like you're referencing a public field.

[Ben Newsam]

On Tue, 24 Oct 2006 11:35:26 -0700, "Peter Duniho"
<Np*********@NnOwSlPiAnMk.comwrote:

>To me, properties are nouns and adjectives related to the class, while
methods are the verbs of the class.

That's a good rule of thumb.

--
Posted via a free Usenet account from http://www.teranews.com

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>>
Otherwise, I don't see the point in writing both getters and setters
instead
of making fields public. I think both approaches represent code smells,
but
that the latter is more intention-revealing and less messy than the
latter.
It's also more agile, in not writing code that's not needed.

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

///ark

[Arne Vajhøj]

Paul Mcilreavy wrote:

Hi, i would like to get some view points on the use of properties within
classes. My belief is that properties should generally be used to return
values of private members. They should not do anything that is likely to
return an error and they should not instantiate or return any big objects
etc.

My company seems to be using them for everything which is starting to cause
me concern. Any comments or other viewpoints is appreciated.

1) a get should not change the object
2) a get should never throw an exception but may return null
3) a set may throw an exception
4) a get after a set should return the value just set
5) multiple set with the same value should have the same
effect as one set with that value

is what I would expect of a property.

Arne

[Arne Vajhøj]

Martijn Mulder wrote:

>Hi, i would like to get some view points on the use of properties

Properties are best avoided. They seem great at first, but in fact they
obscure your code. Suddenly there is a third kind of class member, data,
functions (methods) and now, NEW NEW NEW, properties. My experience is, when
I want to get some value, I use Get...(), when I want to set something, I
use Set...(value); Then you know where to look for what happens.

Of course you could do it with methods. C++ and Java does that.

But other C# programmers use and expect to see properties.

Whether or not you like properties as a concept does not
matter. To provide consistent code you should follow common
C# coding conventions. This includes properties.

I don't think properties is a benefit for the language, but
I do use them.

Arne

[Arne Vajhøj]

Martijn Mulder wrote:

Using properties is not a problem and indeed it looks rather neat. Writing
and maintaining your own properties does give some headache. Where, for
example, do you store them in the source file? I put fields at top, then the
constructor(s) followed by the methods, in alphabetical order. Properties
landed between the fields and the constructor, were hard to find, were hard
to maintain.

Switch from notepad to an IDE.

The have tools to help navigate.

Arne

[Peter Duniho]

"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...

Would the source compatibility part apply only to ref arguments?

No. If you want to later encapsulate the behavior of what was previously a
public field, you will require any user of the class to be modified and
recompiled.

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@communitymtm.comwrote:

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

Yes, unless reflection is being used.

Of course, using fields means you can't use an interface to define the
contract of the class (or at least, you can't include the field in the
contract, whereas you can include a property).

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case
for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

Yes, unless reflection is being used.

Okay, now I'm a little lost I think. I must be reading "source
compatibility" differently than intended, since I got the exact opposite
answer to the question than you did. :)

My interpretation:

"binary compatibility" -- you don't need to recompile
"source compatibility" -- you don't need to change the source code

In other words, if you have a public field, and decide to make that private
to support some desired behavior that using a property gives you, you have
to go modify the code. That breaks what I know as "source compatibility".

So, clue me in...what ARE you guys talking about, and why does it only
affect "ref arguments"? (which I read to mean "arguments using the 'ref'
keyword"...that is, arguments passed by reference).

Thanks,
Pete

[Christof Nordiek]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comschrieb im Newsbeitrag
news:12*************@corp.supernews.com...

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case
for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

Yes, unless reflection is being used.

Okay, now I'm a little lost I think. I must be reading "source
compatibility" differently than intended, since I got the exact opposite
answer to the question than you did. :)

My interpretation:

"binary compatibility" -- you don't need to recompile
"source compatibility" -- you don't need to change the source code

In other words, if you have a public field, and decide to make that
private to support some desired behavior that using a property gives you,
you have to go modify the code. That breaks what I know as "source
compatibility".

This surely would break source compatibility as well as binary comptability.
What they meant is replacing the public Field with property of the same
name, with a field with another name. Since access to fields an properties
are same in C# but different in IL that wouldn't break source compatibility
but binary compatability.

>
So, clue me in...what ARE you guys talking about, and why does it only
affect "ref arguments"? (which I read to mean "arguments using the 'ref'
keyword"...that is, arguments passed by reference).

Fields can by passed as ref/out parameters while properties can't.

>
Thanks,
Pete

[Marc Gravell]

It would also trash any reflective usage that explicetely looks for a
field... so you'd need to look for the field/property name as a string.

Not that I condone reflection as the first answer to a problem, but it has a
few uses...

Marc

[Martijn Mulder]

>Using properties is not a problem and indeed it looks rather neat.

>Writing and maintaining your own properties does give some headache.
Where, for example, do you store them in the source file? I put fields at
top, then the constructor(s) followed by the methods, in alphabetical
order. Properties landed between the fields and the constructor, were
hard to find, were hard to maintain.

Switch from notepad to an IDE.

:-) no, I stick with vim. Working with properties became cumbersome when I
had to decide how to address fields within the class itself. Private,
protected or public is not an issue there, but some of the validation was
stored in the property-accessor. So I had two different outlooks on the same
internal data. My methods, that are usually very short and concise, became
difficult to interpret because raw data access was mingled with
property-based access. One day I decided to kick all home-grown properties
out and that cleared things up a lot (although they seem to be creeping
back)

[Mark Wilden]

"Peter Duniho" <Np*********@NnOwSlPiAnMk.comwrote in message
news:12*************@corp.supernews.com...

>
No. If you want to later encapsulate the behavior of what was previously
a public field, you will require any user of the class to be modified and
recompiled.

I'm talking about converting public fields to public getter/setters. I don't
see how client source would need to be modified (unless the fields were
passed as ref arguments). The client would need to be recompiled (which is
important if and only if binary compatibility is required).

///ark

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>
Of course, using fields means you can't use an interface to define the
contract of the class (or at least, you can't include the field in the
contract, whereas you can include a property).

Again, this is a no-brainer. -IF- you need to do this, then of course you
will use properties. My comment is whether one should just automatically use
getter/setters to wrap fields instead of using public properties when it
is -possible- to do so.

And, again, I feel that getter/setter property pairs are in general a bad
idea anyway.

///ark

[Jon Skeet [C# MVP]]

Mark Wilden <mw*****@communitymtm.comwrote:

Of course, using fields means you can't use an interface to define the
contract of the class (or at least, you can't include the field in the
contract, whereas you can include a property).

Again, this is a no-brainer. -IF- you need to do this, then of course you
will use properties. My comment is whether one should just automatically use
getter/setters to wrap fields instead of using public properties when it
is -possible- to do so.

And, again, I feel that getter/setter property pairs are in general a bad
idea anyway.

When are they a bad idea but public fields are a *good* idea?

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
If replying to the group, please do not mail me too

[Peter Duniho]

"Mark Wilden" <mw*****@communitymtm.comwrote in message
news:%2******************@TK2MSFTNGP05.phx.gbl...

>No. If you want to later encapsulate the behavior of what was previously
a public field, you will require any user of the class to be modified and
recompiled.

I'm talking about converting public fields to public getter/setters. I
don't see how client source would need to be modified (unless the fields
were passed as ref arguments).

Ahh...I guess for some reason I just assumed that in the process, the public
field would be renamed. On reflection, I see that was a dumb assumption.
:)

Not sure why I made that assumption...I mean, I use fairly strict naming
conventions in which the names of fields and the names of properties would
never be the same, but then I would never make a public field anyway, so my
own personal preferences obviously have nothing to do with the way someone
else might do it. :)

Thanks...

Pete

[Mark Wilden]

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

>And, again, I feel that getter/setter property pairs are in general a bad
idea anyway.

When are they a bad idea but public fields are a *good* idea?

What I was saying is that they are both code smells. "Encapsulating" full
access to one's innards simply by wrapping those innards in properties is
usually just a band-aid.

[Bruce Wood]

Peter Duniho wrote:

"Jon Skeet [C# MVP]" <sk***@pobox.comwrote in message
news:MP************************@msnews.microsoft.c om...

On the other hand, it can cause problem if you *later* want any of the
above - you break both source and binary compatibility.

If binary compatibility is necessary, then you have to make up-front
decisions that would otherwise be better deferred. That's not the case
for
most code, at least in my experience.

Would the source compatibility part apply only to ref arguments?

Yes, unless reflection is being used.

Okay, now I'm a little lost I think. I must be reading "source
compatibility" differently than intended, since I got the exact opposite
answer to the question than you did. :)

My interpretation:

"binary compatibility" -- you don't need to recompile
"source compatibility" -- you don't need to change the source code

I think that you need to narrow what you mean by "source code".

"binary compatibility" -- you don't need to recompile _client_
applications for changes in the library code.
"source compatibility" -- you don't need to change the code of _client_
applications for changes in the library code.

In all cases, of course, you have to change the source code for the
class in question, and recompile.

So if you make a public field private and make a public property for
it, you of course have to recompile the code for that class.
Compatibility just asks whether you have to recompile / modify any of
the code _using_ the changed class.