Variables and Propertires both represent values that you can access.However, there are differences in storage and implementation.
Variables: A variable corresponds directly to a memory location. you define a variable with a single declaration statement. A variable can be a local variable, defined inside a procedure and available only within that procedure,
or it can be a member variable, defined in a module, class, or structure but not inside any procedure .
a member variable is also called a field.
Properties: A property is a data element defined on a module, class, or structure. you define a property with a code block between the Property and End Property Statements.
The code block contain the Get Procedure, a Set procedure, or both.
These procedures are called property procedures or Property accessors.
*****
Imp Difference B/W the Variable and Properties:
Point of Difference
Variable
Property
1. Declaration
single declaration
series of statements in a code block
statement
2. Implementation
Single storage Executable code (property procedures)
location
3. storage
Directly associated typically has internal storage not available outside the
with variables property's conaining class or module with variable's.
value
property's value might or might not exist as a stored element.
4. Executable code
none
Must have at least one procedure
5. Read and write access
read/Write or read only
read/write, read-only, or write only
6.Custom actions (in addition
not possible
) can be performed as part of setting or
retrieving property value.to acception or returning value)
Examples:::
public class Car
{
int speed; //Is this sufficient enough if Car will only set and get it.
public Car(int initialSpeed)
{
speed = initialSpeed;
}
//Is this actually necessary, is it only for setting and getting the member
//variable or does it add some benefit to it, such as caching and if so,
//how does caching work with properties.
public int Speed
{
get{return speed;}
set{speed = value;}
}
//Which is better?
public void MultiplySpeed(int multiply)
{
speed = speed * multiply; //Line 1
this.Speed = this.Speed * multiply; //Line 2
//Change speed value many times
speed = speed + speed + speed;
speed = speed * speed;
speed = speed / 3;
speed = speed - 4;
}
}
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 :)
http://www.codinghorror.com/blog/2006/08/properties-vs-public-variables.html
http://blogs.msdn.com/b/vbteam/archive/2009/09/04/properties-vs-fields-why-does-it-matter-jonathan-aneja.aspx
click to enlarge
click to enlarge
click to enlarge
