How is public property with {get; set;} different from a public field?

[csharper]

I know public fields of a class are not recommended:

//version 1: Not recommended
public class Employee {
public string firstName;
//snip
}

And more often than not, we code it the following way:

// version 2:
public class Employee {
public string FirstName {get; set; }
//snip
}

I assume that version 2 is the preferred approach. But in reality, how is version 2 different from version 1? I understand that in version 2, we have the power to control how we can get and set FirstName, but is it true that the public property FirstName in version 2 *as shown above* is equivalentto the public field firstName in version 1?

Thanks.

 

[Arne Vajhøj]

I know public fields of a class are not recommended:

//version 1: Not recommended
public class Employee {
public string firstName;
//snip
}

And more often than not, we code it the following way:

// version 2:
public class Employee {
public string FirstName {get; set; }
//snip
}

I assume that version 2 is the preferred approach. But in reality,
how is version 2 different from version 1? I understand that in
version 2, we have the power to control how we can get and set
FirstName, but is it true that the public property FirstName in
version 2 *as shown above* is equivalent to the public field
firstName in version 1?

Properties has a number of advantages over fields:

1) Even though the default generated property does not have
any special functionality, then special functionality can be
added later without affecting the code using the class - and
it is common to start with all default generated for all
properties and then add special functionality to a few later, and
it is practically impossible to guess at star which one will
need special functionality
2) Properties can be in interfaces, be abstract, be virtual etc.
and thereby work truly object oriented / polymorphed
3) Many libraries/tools are designed to work with properties
and not with fields

(of course #3 is driven by the fact that properties is
the "standard" way of doing it and it can not explain
why it became the "standard", but it can explain why
you should not deviate from the "standard").

Arne

 

[Willem van Rumpt]

I know public fields of a class are not recommended:

//version 1: Not recommended
public class Employee {
public string firstName;
//snip
}

And more often than not, we code it the following way:

// version 2:
public class Employee {
public string FirstName {get; set; }
//snip
}

I assume that version 2 is the preferred approach. But in reality, how is version 2 different from version 1? I understand that in version 2, we have the power to control how we can get and set FirstName, but is it true that the public property FirstName in version 2 *as shown above* is equivalent to the public field firstName in version 1?

Thanks.

Other than for metadata (read: reflection), there is no difference.

I have a strong dislike for these kind of properties; I don't buy the
validity of the "extensibility" argument ("...later, you can add
validation / functionality / whatever..."). Class design doesn't work
that way.

The only reason they're there is for convenience, eliminating the need
for tedious work. I don't use them when designing classes in a
production scenario. When experimenting they're a god sent.

 

[Arne Vajhøj]

Other than for metadata (read: reflection), there is no difference.

I have a strong dislike for these kind of properties; I don't buy the
validity of the "extensibility" argument ("...later, you can add
validation / functionality / whatever..."). Class design doesn't work
that way.

The only reason they're there is for convenience, eliminating the need
for tedious work. I don't use them when designing classes in a
production scenario. When experimenting they're a god sent.

I am not quite sure if you are arguing to use fields instead of
default properties or if you are arguing to use the long form for
properties instead of the short form.

Arne

 

[Willem van Rumpt]

I am not quite sure if you are arguing to use fields instead of
default properties or if you are arguing to use the long form for
properties instead of the short form.

Ah yes, sorry, it is not clear from my post.

I'm advocating the use of long form properties, instead of short form;
definitely not the use of public fields instead of properties.

I tend to encounter the short form properties quite a lot in other code,
and although there's of course technically nothing wrong with it, it
gives me the feel that the owning type is nothing more than just a
property bag. It has a ring to it of using properties because that's
"what one is supposed to do", instead of thinking about why there should
be a property at all: They seem to have been put there on the basis of
some "...now just slam on some properties on this baby for good measure,
and: Done, another class...".

I end up almost invariably writing properties which have a backing
field. In most cases, it gives some guideline, support and validity in
determining whether there should be a property at all.

 

[Arne Vajhøj]

Ah yes, sorry, it is not clear from my post.

I'm advocating the use of long form properties, instead of short form;
definitely not the use of public fields instead of properties.

I tend to encounter the short form properties quite a lot in other code,
and although there's of course technically nothing wrong with it, it
gives me the feel that the owning type is nothing more than just a
property bag. It has a ring to it of using properties because that's
"what one is supposed to do", instead of thinking about why there should
be a property at all: They seem to have been put there on the basis of
some "...now just slam on some properties on this baby for good measure,
and: Done, another class...".

I end up almost invariably writing properties which have a backing
field. In most cases, it gives some guideline, support and validity in
determining whether there should be a property at all.

I don't have a problem with people starting with the short form and
convert to the long form when needed.

But I understand your argument.

Arne

 

[Willem van Rumpt]

IMHO, one of the biggest advantages of the short form is that it makes
it easier to follow good programming practices from the outset. That is,
when you're initially creating your class and all you know is that you
need the property and you want a placeholder, you can get the basic
functionality working quickly without a lot of boilerplate.

I can agree with removing the boilerplate, it's quick and functional; My
preference for the long form is more a personal thing than a dogma,
although perhaps I didn't make that clear enough. It's probably a result
of reviewing code with properties all over the place, that were added on
the basis of some I-probably-will-need-this idea, and were then never
removed.

This results in classes that end up exposing everything that a class
*can* tell about itself, not what class *should* tell about itself. I
realize that short-form properties can't be blamed for this in itself
(and I'm also not advocating removal or outlawing this feature), it's a
design issue, but it makes it oh so easy to saturate a class with
properties, that no one needs.

Another big advantage is the creation of simple, immutable data types.
EventArgs sub-classes being a prime example. They don't really do
anything, they just hold some data. But most of the time, you want that
data to be simple and the properties read-only. The "get; private set"
syntax is a nice time-saver in that scenario.

True, I'm with you here. I do the same for those kinds of classes that
are essentially property bags. Although for some reason, I never used
the "get; private set;" shortcut for EventArgs classes. Very practical
indeed.

 

[Willem van Rumpt]

I don't have a problem with people starting with the short form and
convert to the long form when needed.

But I understand your argument.

My issue is more with the degradation of classes and design (see my
reply to Pete), than with anything else. From what I get to see on a
daily basis, the short form properties tend to stick around, even when
not needed anymore. But, as I remarked in my reply to Pete, it's more a
design issue, and, come to think of it, training and teaching people
good design.

 

[Registered User]

My issue is more with the degradation of classes and design (see my
reply to Pete), than with anything else. From what I get to see on a
daily basis, the short form properties tend to stick around, even when
not needed anymore. But, as I remarked in my reply to Pete, it's more a
design issue, and, come to think of it, training and teaching people
good design.

It also might be a management issue as in 'we can fix that later'.

regards
A.G.