Property (without additional processing) against the public field

Question

Whenever a question arises about the validity of properties, I see that most discussions take place around functions / methods and properties. But I would also like to know the reason convincing to use the property with the corresponding private field against the open field directly, including the most common get / set methods without any other processing, I mean this way

public string CustomerName; 

against

 private string customerName; public string CustomerName { get{return customerName;} set(string value){this.customerName=value;} } 

Answer 1

You get the original / binary compatibility, if later you need to add other behavior, you can add breakpoints, and it's just philosophically cleaner (care about behavior, not storage mechanism).

Note that you do not need the entire last block in C # 3:

 public string CustomerName { get; set; } 

For more information, see my article “Why Properties of Matter” .

Answer 2

• You can override or at least create a “new” property in a derived class

• At this point, people expect properties to be exposed and fields to be hidden. If someone reflects on your class (it becomes more and more common with tools like Castle Windsor, NHibernate), there is a world of differences, most likely they will not check open fields.

Answer 3

This is basically a bug in Java. In many other languages ​​(Python, Delphi, Groovy), the compiler will generate getters and setters for you if you do not provide the code.

This means that you can use the “public” field in Groovy, and the compiler will silently generate and call setter / setter. If you need to do extra magic when changing the field, you can enter a specialized setter, and everything will work.

This is one of those things where reality is confronted with design. The Java developers did not want the compiler to do everything that you do not see. What seemed like a good idea many years ago did not work out too well.

Answer 4

I notice one useful use of the property. If you intend to bind your object's collection to a DataGrid or DataGridView or other related control, the only recognized valued names are Property, not public fields.

Answer 5

You can also provide a basic property check. For example, to prevent the property from being set to an invalid state, for example, a negative value for height:

 private int height; public int Height { get{ return height; } set { if (value > 0) { height = value; } } } 

Answer 6

Even without additional processing, there are several more advantages:

1. Good coding practice. In general, it’s good not to expose your fields directly to external classes, but instead to allow them access only through this additional level of abstraction. Even without additional processing, it is still good to be consistent, as this may be needed somewhere else in the code.
2. You may need to change the field to a property later when you have several other projects depending on yours. This will require recompiling everything.
3. You can use events with them, such as attaching handlers to PropertyChanging or PropertyChanged events. In the case of fields this is not possible.