CODEWITHSUNDEEP
c#
John Doe
John Doe

Reputation: 3233

Properties in a Class

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; }
        }
}

Upvotes: 0

Views: 120

Answers (7)

Matthias Meid
Matthias Meid

Reputation: 12503

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.

Upvotes: 0

Botz3000
Botz3000

Reputation: 39600

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.

Upvotes: 2

Aniket Inge
Aniket Inge

Reputation: 25695

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*/

Upvotes: 1

Fls'Zen
Fls'Zen

Reputation: 4654

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.

Upvotes: 0

p.s.w.g
p.s.w.g

Reputation: 148980

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; }

Upvotes: 0

Colin Mackay
Colin Mackay

Reputation: 19175

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)

Upvotes: 0

Justin
Justin

Reputation: 86729

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

Upvotes: 5

Related Questions