Properties in a Class

Question

What is the difference (i.e. advantage/disadvantage) between the 2 properties that I created? Both seem to be correct, but what is the best way (practice) of declaring properties in a class?

[Serializable]
public class MySample
{
   public string String1 = string.Empty;

   private string _string2 = string.Empty;

   public string String2 
        {
            get { return _string2 ; }
            set { _string2 = value; }
        }
}

Possible duplicate http://stackoverflow.com/questions/450238/to-underscore-or-to-not-to-underscore-that-is-the-question — coder, Feb 20 '13 at 15:22
If you want, for example, to raise an event when the property have been change. You are forced to go with the "String2" option since its the only one where you can place code in the set / get accessors. — Evelie, Feb 20 '13 at 15:24
possible duplicate of [Property(with no extra processing) vs public field](http://stackoverflow.com/questions/1272521/propertywith-no-extra-processing-vs-public-field) — nawfal, Jul 17 '14 at 20:37

score 5 · Accepted Answer · edited May 23 '17 at 10:24

5

Only String2 is a property, the other is a public field.

See Difference between Property and Field in C# .NET 3.5+ for detail but if in doubt you should use properties rather than public fields.

If that seems like too much typing then you will be pleased to know that the following is equivalent

public string String2 { get; set; }

See auto-properties

edited May 23 '17 at 10:24

Community

1
1

answered Feb 20 '13 at 15:21

Justin

84,773
49
224
367

Botz3000 · Answer 2 · 2013-02-20T15:34:17.933

Only String2 is a property. String1 is just a public field, and it is recommended to not declare public fields.

You can simplify the declaration of simple properties like this by using automatic properties:

public string String { get; set; }

The main difference between fields and properties is that fields are accessed directly, whereas properties are read and written to via get and set methods. When you declare an automatic property as above, these get and set methods are automatically generated for you by the compiler, as well as a backing field to store the actual value.

You can also execute additional code in the get and set methods, which is often used for things like change notification and validation. You can set the get and set methods to different visibilities, such as { get; private set; }, which is another thing that you don't have with fields.

Note that even if the usage of String1 and String2 in your example is the same, they are not binary compatible. That is, if you have a class that uses a field and you want to change that field to a property, you'll need to recompile all assemblies referencing that class. So it's best to go with (at least automatic) properties from the beginning.

Aniket Inge · Answer 3 · 2013-02-20T15:29:33.227

1

The best way is to use auto-properties:

like this:

public string String1 {get;set;}

If you want a property from which you only read from, but not write to:

public string String1 {get; private set;}

If you want a property to which you only write to, but not read from:

public string String1 {set; private get;}

Generally it is recommended that you should not declare fields as public:

public string _string1; /*bad idea*/

edited Feb 20 '13 at 15:29

answered Feb 20 '13 at 15:21

Aniket Inge

25,375
5
50
78

your declaration of a read-only property is wrong. You are missing `private set;` The same goes for the write-only property. – Daniel Hilgarth Feb 20 '13 at 15:26
@DanielHilgarth am I OK now? – Aniket Inge Feb 20 '13 at 15:29
Now it compiles. However, convention says that a setter should always be placed after a getter. BTW: A write-only property is also a *bad idea* and shouldn't be used. – Daniel Hilgarth Feb 20 '13 at 15:33

Matthias Meid · Answer 4 · 2013-02-20T16:15:32.030

0

String1 is a public field, not a property. This is not recommended unless it's static readonly (and immutable!), like String.Empty.

Even if a field is fine now (though propably not state-of-the-art), changing it into a property later on breaks the binary compatibility of your class and thus is a breaking change.

edited Feb 20 '13 at 16:15

answered Feb 20 '13 at 15:22

Matthias Meid

12,455
7
45
79

score 0 · Answer 5 · answered Feb 20 '13 at 15:22

The first this is that :

public string String1 = string.Empty;

is a field, not a property. You should generally avoid making public fields.

The second is a property with a field backer. This can be useful if you want to do some sort of validation before setting it. Or maybe have some sort of lazy initialisation before getting the value (obviously the lazy initialisation works better for more complex types or where the construction of the value, if not needed often, takes time).

The third option is an auto property, like this:

public string String3 { get; set; }

This compiles like a property, so if you change your code to be a field backed property to add extra functionality, then the signature of your class doesn't have to change and any existing code that uses the class won't need to be updated to call a property instead of a field (since it always was a property)

score 0 · Answer 6 · edited May 23 '17 at 12:34

0

The first is not a property, but a field. The way you've implemented these here, there's effectively no difference, but in general, properties give you a lot more power.

See What is the difference between a Field and a Property in C#?

The usual way to implement a property in C# is:

public string String1 { get; set; }

edited May 23 '17 at 12:34

Community

1
1

answered Feb 20 '13 at 15:23

p.s.w.g

146,324
30
291
331

score 0 · Answer 7 · answered Feb 20 '13 at 15:24

Your String1 is actually a field, not a property. I suppose you were wanting an auto-implemented property, such as:

public string String1 { get; set; }

Your String2 is a field-backed property. One of the main differences between the two is that you have the opportunity to initialize the field-backed property by initializing the field instead of initializing the property in the constructor. Another important difference is that you have the opportunity in the field-backed property to do other things when the value is retrieved or set, such as performing change notification.

Properties in a Class

7 Answers7