Why simple properties?

[pinkfloydhomer]

I can understand why properties are neat if you want to limit access
(only get, no set), or you want to do some bookkeeping or sanity
checking on values (in set) or if you want to change the underlying
type without changing the property type etc.

But what is the use for properties like:

private int data;

public int Data
{
get
{
return data;
}

set
{
data = value;
}
}
?

I see this a lot. For all intents and purposes, you might just have a
public member instead. Even if you wanted to change the public member
later to a property, your interface would still be maintained. No
possibilities lost.

/David

[Jon Skeet [C# MVP]]

On Oct 3, 10:28 am, "pinkfloydho... @gmail.com"
<pinkfloydho... @gmail.comwrote :

<snip>

I see this a lot. For all intents and purposes, you might just have a
public member instead. Even if you wanted to change the public member
later to a property, your interface would still be maintained. No
possibilities lost.

No, the interface isn't maintained. There are various things you can
do with fields (such as passing them by reference) which you can't do
with properties. Likewise there are things which work with properties
(such as databinding) which don't work with fields. Anything using
reflection or serialization is likely to break as well.

It's best to use properties right from the start - I don't like having
any fields which aren't private. I see that it's a slight pain to have
the whole property code, but C# 3 will make this simpler:

public string Foo { get; private set; }

for instance.

Jon

[John Duval]

On Oct 3, 5:28 am, "pinkfloydho... @gmail.com"
<pinkfloydho... @gmail.comwrote :

I can understand why properties are neat if you want to limit access
(only get, no set), or you want to do some bookkeeping or sanity
checking on values (in set) or if you want to change the underlying
type without changing the property type etc.

But what is the use for properties like:

private int data;

public int Data
{
get
{
return data;
}

set
{
data = value;
}

}

?

I see this a lot. For all intents and purposes, you might just have a
public member instead. Even if you wanted to change the public member
later to a property, your interface would still be maintained. No
possibilities lost.

/David

Hi David,
In addition to what Jon said, I also find it handy to have the
property accessors as a central place to set a breakpoint (or add log
line) to help in debugging.
John

[Chris Shepherd]

As an addition to what other people have said, consider that your
current needs may also not be your future needs. Are you really going to
want to go through everything and change your variable use to property
use if you decide you do need some kind of sanity checking/other things
going on whenever that property is assigned? Personally, I think it
helps a bit with future-proofing as well.

Chris.

[Chris Mullins [MVP - C#]]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote

No, the interface isn't maintained. There are various things you can
do with fields (such as passing them by reference) which you can't do
with properties. Likewise there are things which work with properties
(such as databinding) which don't work with fields. Anything using
reflection or serialization is likely to break as well.

I never quite thought of that, but you're completly right.

I'll remember these reasons, as I see this come up quite often during code
reviews. I kick code back with "Make these properties" and a debate then
begins.

--
Chris Mullins

[Chris Mullins [MVP - C#]]

"John Duval" <Jo********@gma il.comwrote in message:

In addition to what Jon said, I also find it handy to have the
property accessors as a central place to set a breakpoint (or add log
line) to help in debugging.

Just to be nitpicky (sorry, I can't help myself!), you can do both of those
with a variable as well.

Set a breakpoint on the variable, right click on the little red circle, and
select "When hit". Up will come a dialog box that lets you do all sorts of
fun. It's quite powerful, and is a big aid to debugging (as are all the
'Advanced' breakpoint functions).

Of course, you can do all this with a property accessor too, but even then I
often end up setting the breakpoint on the variable itself, in case
something unforseen is going on...

--
Chris Mullins

[Jon Skeet [C# MVP]]

On Oct 4, 10:57 am, this.final...@g mail.com wrote:

You mean apart from proper encapsulation? Variable names are an
implementation detail, IMO.

For a read-write property the underlying field is exposed to the
outside and there isn't any encapsulation to care about.

No - the field's *value* is exposed, but not the field itself. I can
rename the field to my heart's content - it's an implementation
detail.

One might as
well make the field public. This gives clearer, crisper and easier to
maintain code. The rule "Never use public fields" isn't proper
encapsulation. Proper encapsulation is to hide fields that are not
needed from the outside, but also to realize that once in a while some
internal data of an object must be exposed and public fields are a
good candidate to implement this behavior.

Only if you deem the fact that it's directly stored as a field without
even the *potential* for validation or other storage as part of the
specification. I think that locks things down too much, personally.

I believe that a field is too low-level a concept to be part of the
exposed API for a well-designed component.

Because DaInterface has specified a property, and it isn't being
implemented in the ImplementerClas s. Yes, C# *could* generate a
property instead, but that would give two very different syntaxes for
properties.

If some property should be a simple read-write property doing nothing
but copying the value, then why not just implement it as a public
field? One might speculate that maybe in the future the distinction
between field and property will disappear, "field" would just be
shorthand for a non-restricted property with no method body.

I think that's very unlikely, seeing as they're logically different
things. A field is a storage location; a property is way of accessing
data. Changing between the two changes behaviour in various ways -
code using a read/write field may not compile when using a property
(think "pass by reference"), reflection will see different things,
etc.

In C# 3 life will be much simpler though:

public int Something { get; set; }

Ok, that looks neat. But, still, I would read that as: Something is
like a public field. And I would then erase the curly braces thing,
because it's redudant.

But it's *not* a public field. There's a different in the metadata,
there are different semantics in various ways. Why try to pretend it's
something it's not?

Jon

[John Duval]

On Oct 3, 1:03 pm, "Chris Mullins [MVP - C#]" <cmull...@yahoo .com>
wrote:

"John Duval" <JohnMDu...@gma il.comwrote in message:

In addition to what Jon said, I also find it handy to have the
property accessors as a central place to set a breakpoint (or add log
line) to help in debugging.

Just to be nitpicky (sorry, I can't help myself!), you can do both of those
with a variable as well.

Set a breakpoint on the variable, right click on the little red circle, and
select "When hit". Up will come a dialog box that lets you do all sorts of
fun. It's quite powerful, and is a big aid to debugging (as are all the
'Advanced' breakpoint functions).

Of course, you can do all this with a property accessor too, but even then I
often end up setting the breakpoint on the variable itself, in case
something unforseen is going on...

--
Chris Mullins

Hi Chris,
Not sure I follow what you mean. If you have two classes like this:

public class TestClass1
{
public string TestValue; // breakpoint can NOT be set
}

public class TestClass2
{
private string _testValue;
public string TestValue { set { _testValue = value; } } //
breakpoint can be set
}

You can set a breakpoint whenever TestValue is set on TestClass2, but
you can't do it for TestClass1. Are we talking about the same thing?

And I agree about the "When Hit..." breakpoint options, they're very
useful.
John

[Ben Voigt [C++ MVP]]

"John Duval" <Jo********@gma il.comwrote in message
news:11******** **************@ g4g2000hsf.goog legroups.com...

On Oct 3, 1:03 pm, "Chris Mullins [MVP - C#]" <cmull...@yahoo .com>
wrote:

>"John Duval" <JohnMDu...@gma il.comwrote in message:

In addition to what Jon said, I also find it handy to have the
property accessors as a central place to set a breakpoint (or add log
line) to help in debugging.

Just to be nitpicky (sorry, I can't help myself!), you can do both of
those
with a variable as well.

Set a breakpoint on the variable, right click on the little red circle,
and
select "When hit". Up will come a dialog box that lets you do all sorts
of
fun. It's quite powerful, and is a big aid to debugging (as are all the
'Advanced' breakpoint functions).

Of course, you can do all this with a property accessor too, but even
then I
often end up setting the breakpoint on the variable itself, in case
something unforseen is going on...

--
Chris Mullins

Hi Chris,
Not sure I follow what you mean. If you have two classes like this:

public class TestClass1
{
public string TestValue; // breakpoint can NOT be set
}

public class TestClass2
{
private string _testValue;
public string TestValue { set { _testValue = value; } } //
breakpoint can be set
}

You can set a breakpoint whenever TestValue is set on TestClass2, but
you can't do it for TestClass1. Are we talking about the same thing?

And I agree about the "When Hit..." breakpoint options, they're very
useful.
John

Also, data breakpoints only work in native code, because if the garbage
collector moves the object... MS needs to get their debugging act together
and make the GC update breakpoint registers pointing into the managed heap.

[Ben Voigt [C++ MVP]]

"Jon Skeet [C# MVP]" <sk***@pobox.co mwrote in message
news:11******** *************@y 42g2000hsy.goog legroups.com...

On Oct 4, 10:57 am, this.final...@g mail.com wrote:

You mean apart from proper encapsulation? Variable names are an
implementation detail, IMO.

For a read-write property the underlying field is exposed to the
outside and there isn't any encapsulation to care about.

No - the field's *value* is exposed, but not the field itself. I can
rename the field to my heart's content - it's an implementation
detail.

You cannot rename the public member. Fields and properties are alike in
that regard.

>

>One might as
well make the field public. This gives clearer, crisper and easier to
maintain code. The rule "Never use public fields" isn't proper
encapsulatio n. Proper encapsulation is to hide fields that are not
needed from the outside, but also to realize that once in a while some
internal data of an object must be exposed and public fields are a
good candidate to implement this behavior.

Only if you deem the fact that it's directly stored as a field without
even the *potential* for validation or other storage as part of the
specification. I think that locks things down too much, personally.

I believe that a field is too low-level a concept to be part of the
exposed API for a well-designed component.

Even for something like System.Drawing. Point?

What about interop structures?