Var vs Object type

  • Thread starter Thread starter tshad
  • Start date Start date
T

tshad

I am curious as to why to use var in place of an Object Type?

If you have the following program that I found online - var is used:
*************************************
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TomsTestApp
{
class Order
{
private int _OrderID;
private int _CustomerID;
private double _Cost;
public int OrderID
{
get { return _OrderID; }
set { _OrderID = value; }
}
public int CustomerID
{
get { return _CustomerID; }
set { _CustomerID = value; }
}
public double Cost
{
get { return _Cost; }
set { _Cost = value; }
}
}
class Program
{
static void Main(string[] args)
{
// Set up some test orders.
var Orders = new List<Order> { // Change var to
List<Order>
new Order {
OrderID = 1,
CustomerID = 84,
Cost = 159.12
},
new Order {
OrderID = 2,
CustomerID = 7,
Cost = 18.50
},
new Order {
OrderID = 3,
CustomerID = 84,
Cost = 2.89
}
};
// Linq query.

Console.WriteLine(Orders.GetType());

var Found = from o in Orders
where o.CustomerID == 84
select o.Cost;

// Display results.
foreach (var Result in Found)
Console.WriteLine("Cost: " + Result.ToString());
Console.Read();
}
}
}
************************************

If I change the "var" above to List<Order>, the program works equally well.

So why would you use var?

Thanks,

Tom
 
tshad said:
I am curious as to why to use var in place of an Object Type?

If you have the following program that I found online - var is used:
*************************************
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace TomsTestApp
{
class Order
{
private int _OrderID;
private int _CustomerID;
private double _Cost;
public int OrderID
{
get { return _OrderID; }
set { _OrderID = value; }
}
public int CustomerID
{
get { return _CustomerID; }
set { _CustomerID = value; }
}
public double Cost
{
get { return _Cost; }
set { _Cost = value; }
}
}
class Program
{
static void Main(string[] args)
{
// Set up some test orders.
var Orders = new List<Order> { // Change var to
List<Order>
new Order {
OrderID = 1,
CustomerID = 84,
Cost = 159.12
},
new Order {
OrderID = 2,
CustomerID = 7,
Cost = 18.50
},
new Order {
OrderID = 3,
CustomerID = 84,
Cost = 2.89
}
};
// Linq query.

Console.WriteLine(Orders.GetType());

var Found = from o in Orders
where o.CustomerID == 84
select o.Cost;

// Display results.
foreach (var Result in Found)
Console.WriteLine("Cost: " + Result.ToString());
Console.Read();
}
}
}
************************************

If I change the "var" above to List<Order>, the program works equally well.

So why would you use var?

Thanks,

Tom
Click to expand...

For the above var Orders [...] it merely saves you some typing, but when
it comes to Linq query (var Found [...]), do you know what type it is?
What you probably know is, it does implement IEnumerable interface but
do you know the actual type is? The Linq query may become much more
complex than the above, so var is of great help.

Regards.
 
[...]
If I change the "var" above to List<Order>, the program works equally
well.
So why would you use var?
Click to expand...

For the above var Orders [...] it merely saves you some typing, but when
it comes to Linq query (var Found [...]), do you know what type it is?
What you probably know is, it does implement IEnumerable interface but
do you know the actual type is? The Linq query may become much more
complex than the above, so var is of great help.
Click to expand...

To elaborate:

For many LINQ expressions, you _do_ know the resulting type and could in
fact specify the correct type for the variable.

But the essential use of "var" is for situations (most commonly LINQ
expressions, but not restricted to that use) where one has created an
anonymous type and needs to assign that or something including that type
(e.g. an IEnumerable<T> of that type) to a variable. What type name would
you specify for the declaration, given that the type has no name?

Thus, we have "var". It's the type "name" you put when you have no way to
know the actual name of the type. Of course, people use it for lots of
other reasons now that it's there. But that's really the only reason it's
there.

Pete
 
Thus, we have "var". It's the type "name" you put when you have no way to
know the actual name of the type. Of course, people use it for lots of
other reasons now that it's there. But that's really the only reason it's
there.
Click to expand...

For example, I quite often use it íf I'm instantiating some type with a long
name.
An example off the top of my head (maybe not realistic, but you get the
idea):

var users = new List<IDictionary<string, KeyValuePair<string, string>>>()

Simply so I don't have to write the whole type out twice.

One of the "beauties" of var is that a variable declared var, really is of
the type it is instantiated as, as opposed to declaring the variable as
object. For example, I could instantiate two identical types:

var userV = new List<IDictionary<string, KeyValuePair<string, string>>>();
object userO = new List<IDictionary<string, KeyValuePair<string,
string>>>();

With the var "userV" I have access (also intellisense) to the methods of
List. With the object "userO" I only have access to object's methods (well,
unless I cast of course).


/Peter
 
I see.

Thanks,

Tom
Peter K said:
For example, I quite often use it íf I'm instantiating some type with a
long name.
An example off the top of my head (maybe not realistic, but you get the
idea):

var users = new List<IDictionary<string, KeyValuePair<string, string>>>()

Simply so I don't have to write the whole type out twice.

One of the "beauties" of var is that a variable declared var, really is of
the type it is instantiated as, as opposed to declaring the variable as
object. For example, I could instantiate two identical types:

var userV = new List<IDictionary<string, KeyValuePair<string, string>>>();
object userO = new List<IDictionary<string, KeyValuePair<string,
string>>>();

With the var "userV" I have access (also intellisense) to the methods of
List. With the object "userO" I only have access to object's methods
(well, unless I cast of course).


/Peter
Click to expand...
 
Back
Top