Should I use public properties and private fields or public fields for data?

Question

In most of the code I saw (on SO, thecodeproject.com and I usually do this in my own code), I saw that public properties are created for every single private field contained in the class, even if they are the most basic type of get; set; get; set; , eg:

 private int myInt; public int MyInt { get { return myInt; } set { myInt = value } } 

My question is: how is this different from:

 public int MyInt; 

and if we should use properties instead of public fields, why should we use them in this particular case? (I'm not talking about more complex examples where getters and setters really do something special or there is only one get or set (read / write only), and not just return / set the value of the private field). It seems that it does not add additional encapsulation, but only gives a good icon in IntelliSense and is placed in a special section in class diagrams!

Answer 1

See article http://blog.codinghorror.com/properties-vs-public-variables/

In particular

• Reflection works differently in variables and properties, so if you rely on reflection, it's easier to use all the properties.
• You cannot bind data to a variable.
• Changing a variable in a property is a violation of the change.

Answer 2

Three reasons:

• You cannot override fields in subclasses, such as properties.
• Ultimately, you may need a more sophisticated getter or setter, but if this is a field, changing it will break the API.
• Convention This is the way it was done.

I'm sure there are a few more reasons that I just don’t think about.

In .Net 3.x, you can use automatic properties as follows:

 public int Age { get; set; } 

instead of the old school path with declaring your personal fields yourself:

 private int age; public int Age { get { return age; } set { age = value; } } 

This makes it as simple as creating a field, but with no change issues (among other things).

Answer 3

When creating a private name field and a simple public property Name , which actually gets and sets the value of the name field

 public string Name { get { return name; } } 

and you use this property everywhere outside your class, and one day you decide that the Name property of this class will really refer to the lastName field (or what you want to return the string "My name:" + name), you just change the code inside the property:

 public string Name { get { return lastName; //return "My name: "+name; } } 

If you used the public name field everywhere in the external code, you will have to change the name to lastName wherever you used it.

Answer 4

Well, that really matters. Public data may be changed without knowing the instance of the object. Using getters and setters, an object is always aware that a change has been made.

Remember that data encapsulation is only the first step towards a better structured design, it is not an end in itself.

Answer 5

You should use properties in the following cases:

• When you need to serialize data in a property in some format.
• If you need to override properties in a derived class.
• When you implement get and set methods with some logic. For example, when you implement the Singleton template.
• When you are deduced from the interface where the property is declared.
• If you have specific problems with Reflection.

Answer 6

It depends?

I always use getters and setters since they created this shortcut:

public int Foo {get; set; }

At compile time, it is translated. Now you cannot understand what it is, but it is, and if you need to get a fantasy, you just say it later.

However, public, private, secure ... it all depends on who you want to configure the data for. We use inheritance a lot, and this is a very common method for us, so only chidren can edit certain properties.

 protected _foo; public Foo { get { return _foo; } } //lack of set intentional. 

Answer 7

There are many reasons.

Mostly:

• You can perform some other functions when the variable is set.
• You can prevent customization and provide only
• Some "things" work only on properties (for example, DataBinding)
• You can hide the implementation of the property [perhaps this is a ViewState variable in ASP.NET).

Answer 8

The point is, if further down the line you want to make sure that every time myInt referenced, something special happens (the log file is written, it is changed to 42, etc.)? You cannot do this without getters and setters. Sometimes it’s wise to program what you might need, rather than what you need right now.

Answer 9

In fact, if you use Silverlight, you will realize that the fields cannot be set to static resources, and you will have to use the property (even to access const ).

I realized that when I tried to combine the names of the regions that I use in Composite Guidance (PRISM).

However, that there are only language restrictions and besides the static / const fields, I always use properties.

Answer 10

The idea is that you should not accidentally / unintentionally change the value of the class’s private field outside. When you use get and set, it means that you are changing the class’s secret field intentionally and consciously.

Answer 11

Setting a value in a private field only changes this field, but by doing them in a property, you can process other arguments, for example, you can call the method after setting the value

 private string _email;
 public string Email
 {
     get
     {
         return this._email;
     }
     set
     {
         this._email = value;
         ReplaceList ();  // **
     }
 }

Answer 12

Simply put, the answer to your question is access modifiers, that is, public and private.

If you use:

 public int myInt; public int MyInt { get { return myInt; } set { myInt = value } } 

then both the MyInt property and the myInt variable can be changed in the project. So, if your class assumes that A is inherited by class B, then myInt and MyInt are available for modification, and no check can be applied. Suppose you want the value of myInt to be set in an output class if some specific condition has passed.

This can only be achieved by making private individuals and property public. So only a property is available, and conditions can be set on it.

Answer 13

I can't believe that with 11 answers no one said this:

Not all private fields must be open as public. You should definitely use properties for something that should be non-private, but you should save as much of your class as possible.