I have a confusion about understanding Property and Variables
public class ABC() { public int A; public int B { get; set; } }
What is the exact difference between in A and B?
I use properties for the interface part - where the object interfaces with other objects and instance variables are stuff that you need inside your class - nobody but you is supposed to see and manipulate those.
Variables are used to denote the data inside a program. A variable is characterized by the following properties: Name: it is necessary in order to identify the variable; for example: line.
If all you need to do is return a value, use a property. If you need to do something before returning a value, use a function.
Interpretations: "value": it is the actual data or instructions stored in computer. "variable": it is a way locating the data, a value-replacing reference , but not itself the set of data or instruction stored in computer.
As many have pointed out, A is a field, B is a property.
The real question is, why should you care, and what to use?
I refer to a blog post of Jonathan Aneja:
(Its in VB, but it applies to C# as well ;))
So why use properties over fields, 5 reasons:
1. Fields can’t be used in Interfaces
You can’t enforce the existence of a field in an object’s public contract through an interface. For properties though it works fine.
2. Validation
While your application currently may not require any validation logic to set a particular value, changing business requirements may require inserting this logic later. At that point changing a field to a property is a breaking change for consumers of your API. (For example if someone was inspecting your class via reflection).
3. Binary Serialization
Changing a field to a property is a breaking change if you’re using binary serialization. Incidentally, this is one of the reasons VB10’s auto-implemented properties have a “bindable” backing field (i.e. you can express the name of the backing field in code) – that way, if you change an auto-implemented property to an expanded property, you can still maintain serialization compatibility by keeping the backing field name the same (in C# you’re forced to change it because it generates backing fields with unbindable names).
4. A lot of the .NET databinding infrastructure binds to properties but not fields
I’ve heard arguments on both sides as to whether or not that’s a good thing, but the reality is that’s the way it works right now. (Note from me: WPF bindings work on properties)
5. Exposing a public field is an FxCop violation
For many of the reasons listed above :)
There might be more reasons.
I would also like to point to a blog post of Jeff Atwood and conclude with a quote from it:
The really important thing to take away here is to avoid writing code that doesn't matter. And property wrappers around public variables are the very essence of meaningless code.
A is a field, B is a property. A property is basically syntactic sugar for getters and setters. The class you have defined will be compiled into something like this:
public class ABC() { public int A; private int backing_B; public void set_B(int value) { backing_B = value; } public int get_B() { return backing_B; } }
Note that this kind of conversion is true for all C# properties -- accesses to ABC.B will be converted to method calls. Properties basically provide the illusion of a "variable" while actually just being a cleverly disguised pair of methods.
This is important, because it allows you to declare your own get and set method body, which can validate values or do other interesting things:
private int b; public int B { get { return b; } set { if (value < 0) throw new ArgumentOutOfRangeException("value"); b = value; } }
Note that most properties will use a field to store their value. Properties seldom exist on their own, apart from fields.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With