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 4, 3:30 pm, "Ben Voigt [C++ MVP]" <[e-mail] spamwrote:

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.

Yes - but it's not the same as what was claimed - that "for a read-
write property
the field is exposed to the outside".

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?

Yes. In fact, that's a good example - in Java, the Point class exposes
the fields directly. They are integers. When a Point with more
precision was required, a new class had to be created using doubles.
If the Point class had exposed properties instead, the existing
properties could have been kept as integers, the underlying fields
could have been changed to doubles, and new properties could have
exposed the extra precision.

What about interop structures?

They *may* be an exception, because the storage (which is usually an
implementation detail) becomes effectively part of the API. I try to
avoid interop where possible :)

Jon

[Hilton]

FWIW: I would like to see something to make these properties less verbose;
e.g.

public property string Name;
public property int Age;
public property bool Male;

This would just be a compiler directive to create the variables name, age,
and male, as well as the get and set as usual. You could even comment it in
the usual way. This saves a HUGE amount of code and also eliminates the
potential recursive bug.

Hilton

[Jon Skeet [C# MVP]]

On Oct 4, 4:08 pm, "Hilton" <nos...@nospam. comwrote:

FWIW: I would like to see something to make these properties less verbose;
e.g.

public property string Name;
public property int Age;
public property bool Male;

This would just be a compiler directive to create the variables name, age,
and male, as well as the get and set as usual. You could even comment it in
the usual way. This saves a HUGE amount of code and also eliminates the
potential recursive bug.

As I've said, C# 3 has this, but with a slightly different syntax
which avoids introducing any new keywords and still allows different
access for getters/setters. The variable itself is invisible to the
code - it can only use the property.

What C# 3 *doesn't* have (but I'd like) is a way of having custom code
in the property but still hide the variable:

public int Age
{
int age;
// Put more code in here if you want
get { return age; }
set { age = value; }
}

The compiler could still force uniqueness of variable name, but
prohibit access to the variable outside the property - possibly with
exceptions for things like serialization (with an attribute for
methods which want direct access, for instance).

That way the rest of the class is forced to use the property as well,
which aids encapsulation further.

No CLR change would be required for this, which is always nice :)

Jon

[Peter Duniho]

th***********@g mail.com wrote:

For a read-write property the underlying field is exposed to the
outside and there isn't any encapsulation to care about. 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.

I suppose that depends on your definition of "encapsulation" . But the
definition I use definitely includes "never use public fields" as a
mechanism to achieve encapsulation.

The field is an implementation detail. The property is the behavior
exposed by the class. Proper encapsulation hides implementation details
while preserving behaviors. By hiding implementation details, the class
implementation can change arbitrarily, and as long as the class
continues to provide its publicly declared behavior, there's no problem.

There is no way to change from a public field to a public property after
the fact. The difference between the field and a property is a
_behavioral_ difference, and only by changing the _behavior_ of the
class can you modify that part of the design of the class.

But if you use a property from the outset, you can modify your
implementation however you like without having to change the behavior.
This is what encapsulation is all about, and that's why never using
public fields when you can instead use a property is very much part of
proper encapsulation.

Proper encapsulation is to hide fields that are not
needed from the outside,

See, here's the fundamental difference in opinion: you believe that
encapsulation is only about "hiding" things that "are not needed from
the outside".

That's certainly one way to describe it, but it's my opinion that
encapsulation is different from that. The difference is subtle,
granted. But IMHO it's a very real difference.

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.

Well, how about that? I would agree that if "some internal data of an
object must be exposed", then you have to expose it and you have to use
public field to do that. But when does that actually happen? Can you
provide an example?

I'll start out with the obvious one: a class that is actually more like
a struct, and doesn't really have any behavior but is rather just a
place to keep data. All such a class would have is a bunch of public
fields and perhaps a constructor. I agree, no real need for properties
there.

But other than that degenerate class example, in what case is it true
that "some internal data of an object MUST be exposed"?

Pete

[pinkfloydhomer]

On 3 Okt., 11:40, "Jon Skeet [C# MVP]" <[e-mail] 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.

Okay. Seems like kind of an random implementation artifact, and not
some deep language reason.

It's best to use properties right from the start - I don't like having
any fields which aren't private.

In situations where you just want people to be able to access the data
(in simple structs only for holding data etc.), exactly the situations
in which you would make "simple properties" as I called them, and in
which you are fairly sure that this will never change, properties are
just syntactic clutter, IMO. That might change with C# 3.0.

/David

[pinkfloydhomer]

On 4 Okt., 08:39, Jon Skeet [C# MVP] <[e-mail] mwrote:

Yeah, you are right. Public instance variables are very convienient,
e.g. in small struct-like classes whose only purpose is to package
some data fields. There's no need to clutter the code with endless
getters and setters.

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

This has nothing to do with proper encapsulation. Both solutions has
exactly the same degree of encapsulation.
Also, property names are just as much an implementation detail as is
an variable name.

/David

[pinkfloydhomer]

On 4 Okt., 16:42, "Jon Skeet [C# MVP]" <[e-mail] mwrote:

>

Even for something like System.Drawing. Point?

Yes. In fact, that's a good example - in Java, the Point class exposes
the fields directly. They are integers. When a Point with more
precision was required, a new class had to be created using doubles.
If the Point class had exposed properties instead, the existing
properties could have been kept as integers, the underlying fields
could have been changed to doubles, and new properties could have
exposed the extra precision.

But that is precisely because of the seemingly random implementation
choice that properties must be something different than fields. I
can't see why it wouldn't be a better solution to say that a property
has the same interface as a field. Then, if the above situation
happened, you could silently change your fields to properties and
change the type of the underlying fields. I can't see how it is not a
weakness and a random implementation artifact, that this is not
possible.

/David

[Jon Skeet [C# MVP]]

pi************@ gmail.com <pi************ @gmail.comwrote :

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.

Okay. Seems like kind of an random implementation artifact, and not
some deep language reason.

Not a language reason - a design reason. What data a class chooses to
provide access to is part of the encapsulated interface. How it chooses
to store that data *should* be a hidden implementation detail. Exposing
a field exposes that implementation detail.

It's best to use properties right from the start - I don't like having
any fields which aren't private.

In situations where you just want people to be able to access the data
(in simple structs only for holding data etc.), exactly the situations
in which you would make "simple properties" as I called them, and in
which you are fairly sure that this will never change, properties are
just syntactic clutter, IMO. That might change with C# 3.0.

"Syntactic clutter" wouldn't change behaviour though, would it?
Changing a field to a property or vice versa certainly can.

--
Jon Skeet - <sk***@pobox.co m>
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]]

pi************@ gmail.com <pi************ @gmail.comwrote :

Yeah, you are right. Public instance variables are very convienient,
e.g. in small struct-like classes whose only purpose is to package
some data fields. There's no need to clutter the code with endless
getters and setters.

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

This has nothing to do with proper encapsulation. Both solutions has
exactly the same degree of encapsulation.

No, they don't. Using properties, I'm hiding the implementation details
of how data is stored - or *if* it is even stored. Some properties may
be computable, for instance, or the value could be cached. If you
expose a field, you're tying the API to the fact that there's a field
of that type to store the value.

Also, property names are just as much an implementation detail as is
an variable name.

No - when all variables are private, and the properties are public, the
property names are part of the interface but the variable names are
just part of the implementation. I can change the implementation
without changing the public interface.

--
Jon Skeet - <sk***@pobox.co m>
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]]

pi************@ gmail.com <pi************ @gmail.comwrote :

Even for something like System.Drawing. Point?

Yes. In fact, that's a good example - in Java, the Point class exposes
the fields directly. They are integers. When a Point with more
precision was required, a new class had to be created using doubles.
If the Point class had exposed properties instead, the existing
properties could have been kept as integers, the underlying fields
could have been changed to doubles, and new properties could have
exposed the extra precision.

But that is precisely because of the seemingly random implementation
choice that properties must be something different than fields. I
can't see why it wouldn't be a better solution to say that a property
has the same interface as a field. Then, if the above situation
happened, you could silently change your fields to properties and
change the type of the underlying fields. I can't see how it is not a
weakness and a random implementation artifact, that this is not
possible.

If all fields are actually properties, how could you then actually
*store* anything?

The difference between properties and fields is that properties act as
*access* and fields act as *storage*. They're not the same thing, and I
don't see any reason to treat them as the same thing.

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