Properties and Fields

Properties and fields provide access to the data contained in an object. This object data is what differentiates separate objects, because it is possible for different objects of the same class to have different values stored in properties and fields.
 
The various pieces of data contained in an object together make up the state of that object. Imagine an object class that represents a cup of coffee, called CupOfCoffee . When you instantiate this class (that is, create an object of this class), you must provide it with a state for it to be meaningful. In this case, you might use properties and fields to enable the code that uses this object to set the type of coffee used, whether the coffee
contains milk and/or sugar, whether the coffee is instant, and so on. A given coffee cup object would then have a given state, such as ” Columbian filter coffee with milk and two sugars .”
 
Both fields and properties are typed, so you can store information in them as string values, as int values, and so on. However, properties differ from fields in that they don ’ t provide direct access to data. Objects can shield users from the nitty – gritty details of their data, which needn ’ t be represented on a one – to – one basis in the properties that exist. If you used a field for the number of sugars in a CupOfCoffee instance, then users could place whatever values they liked in the field, limited only by the limits of the type used to store this information. If, for example, you used an int to store this data, then users could use any value between – 2147483648 and 2147483647.
 
In general, it is better to provide properties, rather than fields, for state access, because you have more control over various behaviors. This choice doesn ’ t affect code that uses object instances, because the syntax for using properties and fields is the same.
 
Read/write access to properties may also be clearly defined by an object. Certain properties may be read – only, allowing you to see what they are but not change them (at least not directly). This is often a useful technique for reading several pieces of state simultaneously. You might have a read – only property of the CupOfCoffee class called Description , returning a string representing the state of an instance of this class (such as the string given earlier) when requested. You might be able to assemble the same data by interrogating several properties, but a property such as this one may save you time and effort. You might also have write – only properties operating in a similar way.
 
As well as this read/write access for properties, you can also specify a different sort of access permission for both fields and properties, known as accessibility . Accessibility determines which code can access these members — that is, whether they are available to all code (public), only to code within the class (private), or use a more complex scheme. One common practice is to make fields private and provide access to them via public properties. This means that code within the class has direct access to data stored in the field, while the public property shields external users from this data and prevents them from placing invalid content there. Public members are said to be exposed by the class.