Object Initializers and Collection Initializers

New C# Language Features: Automatic Properties, Object Initializers, and Collection Initializers

Question arises:

1. if we use properties like obj.property then why not make those field public even then we can access them like obj.field.

2. Second, if you've got a non-private field, why should you make it private and expose a property instead?

   Solution 1. first thing is that if You can use a property everywhere you can use a field, right? Wrong. You can use a field for ref parameters, whereas you can't (in C# at least) use a property in the same way. There are other subtle areas where there's a difference between fields and properties.

   Second thing is

What are properties?
Just normal variables, like other primitive variables!

Example A:
/////////// ExA.cs //////////////
namespace Rahul
{
using System ;

class Colors
{
public static void Main()
{
UrChoice UrColor = new UrChoice() ;

//Overwriting your favourite color to yellow
UrColor.Color = \"Yellow\" ;
Console.WriteLine(\"Your favourite color is \" + UrColor.Color) ;
}
}

public class UrChoice
{
// Want to provide the access to everybody.
public string Color ;

// Default Constructor setting up your favourite color
public UrChoice()
{
Color = \"White\" ;
}

}

}

Compile the program as: csc ExA.csNow type ExA and press enter (return) key…Output is: Your favorite color is Yellow

In Example 'A', I have declared two classes inRahul namspace:One is UrChoice (as the names are self explanatory) is talking aboutyour choice, not all of your choices but here we are discussing aboutyour favorite color and you have fixed your favorite color as "White"(Just for an instance). Now everybody is free to know about yourfavorite color and he can tell others about your choice.

But there is a problem!
Somebody has changed the value of your favorite color and now your favorite color is Yellow.
Hey! That?s cheating!!!!
Yes! Of course but is there any way to protect your variable or your choice?
Here comes the turn of properties.

Properties are like normal variables but with more power and flexibility.Now we convert the color variable in a property with the same name.

Example B:
////////// ExB.cs //////////////
namespace Rahul
{

using System ;

class Colors
{
public static void Main()
{
UrChoice UrColor = new UrChoice() ;

//Overwriting your favourite color to yellow
UrColor.Color = \"Yellow\" ;
Console.WriteLine(\"Your favourite color is \" + UrColor.Color) ;
}
}

public class UrChoice
{
// your private variable to store your favourite color
private string MyColor ;

// Defining property, Want to provide the access to everybody.
public string Color
{
get{
return MyColor ;
}
}

// Default Constructor setting up your favourite color
public UrChoice()
{
MyColor = \"White\" ;
}
}

}

This time we didn't define color variable as anormal variable rather we defined a property named Color.But in this case we had to define a new variable MyColor to store theinitial and right value of your favorite color (also making it privateto hide it from outside world).
This time when we try to compile our program as: csc ExB.cs
We get an error:
Property or indexer ' Rahul.UrChoice.Color ' can not be assigned to — it is read only.

So, we got actually what we wanted. Now if somebody tries to modify your favorite color, he can not do this.

If you are a C# developer today, you are probably quite used to writing classes with basic properties like the code-snippet below:

public class Person {

private string _firstName;
private string _lastName;
private int _age;

public string FirstName {

get {
return _firstName;
}
set {
_firstName = value;
}
}

public string LastName {

get {
return _lastName;
}
set {
_lastName = value;
}
}

public int Age {

get {
return _age;
}
set {
_age = value;
}
}
}

The new C# compiler that ships in "Orcas" provides an elegant way to make your code more concise while still retaining the flexibility of properties using a new language feature called "automatic properties". Automatic properties allow you to avoid having to manually declare a private field and write the get/set logic -- instead the compiler can automate creating the private field and the default get/set operations for you.

For example, using automatic properties I can now re-write the code above to just be:

public class Person {

public string FirstName {
get; set;
}

public string LastName {
get; set;
}

public int Age {
get; set;
}
}

Or If I want to be really terse, I can collapse the whitespace even further like so:

public class Person {
public string FirstName { get; set; }
public string LastName { get; set; }
public int Age { get; set; }
}

C# 3.0 Automatic Properties explained

So here's the code sample I'm talking about:

 1 using System;  2   3 namespace ConsoleApplication1  4 {  5     class Program  6     {  7         public string Name { get; set; }  8   9         static void Main(string[] args) 10         { 11             var p = new Program(); 12             p.Name = "Bart"; 13         } 14     } 15 }

The clue is on line 7 where I've declared an automatic property. Basically this frees me from the burden of declaring a private variable and a get and set accessor to it by means of a property. Although you can just use the "prop" code snippet in Visual Studio, this is much cleaner in case you don't need the private fields at all. Imagine some entity mapping class that consists of 20 properties, do you want to see all of the private variable, getter and setter noise around your class? I don't think so.

Please notice that the use of automatic properties is not equal to just defining a public field - you still keep the get_PropertyName and set_PropertyName methods behind the scenes as well as all the metadata that goes with a property, as illustrated below:

This means your code can be upgraded at any time to define getters/setters together with an explicitly defined member variable when you need to do so, without having to recompile external consumers of your code (i.e. the "contract" remains untouched). Behind the scenes what happens is the injection of a private member variable, prefixed with <>k__AutomaticallyGeneratedPropertyField#, like this:

.field private string '<>k__AutomaticallyGeneratedPropertyField0' .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 ) 

The CompilerGeneratedAttribute attribute is useful for tools to find out about these auto-generated things. Next, the compiler emits a getter and setter for you:

.method public hidebysig specialname instance string          get_Name() cil managed {   .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )    // Code size       11 (0xb)   .maxstack  1   .locals init (string V_0)   IL_0000:  ldarg.0   IL_0001:  ldfld      string ConsoleApplication1.Program::'<>k__AutomaticallyGeneratedPropertyField0'   IL_0006:  stloc.0   IL_0007:  br.s       IL_0009   IL_0009:  ldloc.0   IL_000a:  ret } // end of method Program::get_Name  .method public hidebysig specialname instance void          set_Name(string 'value') cil managed {   .custom instance void [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor() = ( 01 00 00 00 )    // Code size       8 (0x8)   .maxstack  8   IL_0000:  ldarg.0   IL_0001:  ldarg.1   IL_0002:  stfld      string ConsoleApplication1.Program::'<>k__AutomaticallyGeneratedPropertyField0'   IL_0007:  ret } // end of method Program::set_Name

All the stuff in here is pretty much the same as a manually defined property, except for the presence of the CompilerGeneratedAttribute attribute. Finally, there's the metadata for the property:

.property instance string Name() {   .get instance string ConsoleApplication1.Program::get_Name()   .set instance void ConsoleApplication1.Program::set_Name(string) } // end of property Program::Name

Notice that "automatic properties should have both a getter and a setter" declared. Read-only or write-only properties are not permitted. After all, a typical use for automatic properties is to define "property bag" kind of classes or structs. Of course, there's IntelliSense too:

With the screenshot above I've also shown that local type inference (keyword "var") has now full IDE support (i.e. when you type p. the IDE already knows the type of the variable in order to provide accurate IntelliSense). Enjoy!

Object Initializers

To get started, let's look at the standard way of initializing an object with data in C# 2.0 using constructors. The following example creates a Person object and passes three values to its constructor.

Person person = new Person("Scott", "Guthrie", "32");

As mentioned, C# 3.0 now supports the concept of "object initializers" which means you can easily assign data to specific properties in a type without having to create an explicit constructor (you can of course still create constructors as well). The standard C# { and } brackets are used to create object initializers. Here's an example of using an object initializer to assign property data to a Person type. It's nice because doing the same thing without using a constructor in C# 2.0 would have resulted in around 5 lines of code which is too many for something simple like property value assignments.

Types within the .NET Framework rely heavily on the use of properties. When instantiating and using new classes, it is very common to write code like below:

Person person = new Person();
person.FirstName = "Scott";
person.LastName = "Guthrie";
person.Age = 32;

Have you ever wanted to make this more concise (and maybe fit on one line)? With the C# and VB "Orcas" compilers you can now take advantage of a great "syntactic sugar" language feature called "object Initializers" that allows you to-do this and re-write the above code like so:

Person person = new Person { FirstName="Scott", LastName="Guthrie", Age=32 };

The compiler will then automatically generate the appropriate property setter code that preserves the same semantic meaning as the previous (more verbose) code sample above.

Collection Initializers

New C# and VB Language Feature: Collection Initializers

Object Initializers are great, and make it much easier to concisely add objects to collections. For example, if I wanted to add three people to a generics-based List collection of type "Person", I could write the below code:

List people = new List();

people.Add( new Person { FirstName = "Scott", LastName = "Guthrie", Age = 32 } );
people.Add( new Person { FirstName = "Bill", LastName = "Gates", Age = 50 } );
people.Add( new Person { FirstName = "Susanne", LastName = "Guthrie", Age = 32 } );

List people = new List();

people.Add( new Person { "Scott", "Guthrie", 32 } );
people.Add( new Person { "Bill", "Gates", 50 } );
people.Add( new Person {"Susanne", "Guthrie",32 } );

//above one using constructor

Using the new Object Initializer feature alone saved 12 extra lines of code with this sample versus what I'd need to type with the C# 2.0 compiler.

The C# and VB "Orcas" compilers allow us to go even further, though, and also now support "collection initializers" that allow us to avoid having multiple Add statements, and save even further keystrokes:

List people = new List {
new Person { FirstName = "Scott", LastName = "Guthrie", Age = 32 },
new Person { FirstName = "Bill", LastName = "Gates", Age = 50 },
new Person { FirstName = "Susanne", LastName = "Guthrie", Age = 32 }
};

When the compiler encounters the above syntax, it will automatically generate the collection insert code like the previous sample for us.

Anonymous Methods In C#

An anonymous method is a method without any name. To understand better, a normal method is one which will have a name, return type optionally arguments and an access modifier.

Anonymous methods can be used in the place where there is a use of a delegate. To understand anonymous methods we should understand the usage of delegate first. The following section of this article gives you an idea about delegate.

Understanding Delegate:

Delegate is similar to function pointer in C and C++. A function pointer in C is a variable that points to function. Similarly, a delegate is a reference type in .net that is used to call the methods of similar signature as of the delegate. For example, consider a C# method,

void PrintName(string Name)

{

Response.Write("Name is "+Name+"
");

}

To call the above method using delegate we should declare a delegate with similar signature,

delegate void DelegateTest(string n);

Before calling we should initialize or register the delegate with the method like,

DelegateTest del = new DelegateTest(this.PrintName);

Finally we can call the function by,

Del(“Pankaj”);

So what makes the real difference between C language function pointer and a delegate is, at a given time a function pointer can point to a single function only i.e. it can be used to call a single function only. But delegate are by default they are multicast delegate, means they can be used to call multiple functions at a time. Consider a function,

void PrintAddress(string Address)

{

Response.Write("City he lives is "+Address);

}

The below code will explain how to call PrintName and PrintAddress methods using a delegate,

DelegateTest del = new DelegateTest(this.PrintName);

del += new DelegateTest(this.PrintAddress);

del(“Pankaj”);

So the output will be,

Name is Pankaj

City he lives is Pankaj

It normally does it use of the += operator. So += operator is used to register a function and -= will remove the registration from the delegate. Consider,

DelegateTest del = new DelegateTest(this.PrintName);

del += new DelegateTest(this.PrintAddress);

del -= new DelegateTest(this.PrintAddress);

The output of above code will be,

Name is Pankaj

The other difference between a delegate and a function pointer is, a delegate is type safe, means it will throw a compilation error if a method with different signature is assigned to the delegate.

Back to Anonymous methods: The syntax of an anonymous method consists of the keyword delegate, an optional parameter list and method body enclosed in parenthesis. delegate(Optional parameters) { Body of the method. }; So looking at the answer of the question “Where should I use an Anonymous method?” the anonymous representation to implement the PrintName method will be, delegate void DelegateTest(string n); protected void Page_Load(object sender, EventArgs e) { DelegateTest Anodel = delegate(string Name) { Response.Write("Name is " + Name + " "); }; } Calling is again by, Anodel(“Pankaj”); The output will be, Name is Pankaj
Similar to delegate, To call multiple methods we can use += operator, delegate void DelegateTest(string n); protected void Page_Load(object sender, EventArgs e) { DelegateTest Anodel = delegate(string Name) { Response.Write("Name is " + Name + " "); }; Anodel += delegate(string Address) { Response.Write("City he lives is " + Address); }; Anodel("Pankaj"); } The output will be, Name is Pankaj City he lives is Pankaj

IMPORTANT NOTE : When an anonymous method is declared without parenthesis, it can be assigned to a delegate with any signature.

delegate void DelegateTest(string n);

protected void Page_Load(object sender, EventArgs e)

{

DelegateTest DiffAnodel = delegate

{

Response.Write("

---

Parameterless anonymous method assigned to a delegate with different signature

---

");

Response.Write("Name is Pankaj");

};

DiffAnodel("Pankaj3");

}

The output will be,

Parameterless anonymous method assigned to a delegate with different signature

Name is Pankaj

Thus,

"

we can define an anonymous method as a method without name which allows us to define the body inline."

Why should we use Anonymous method?

We can reduce the code by preventing delegate instantiation and registering it with methods..

It increases the readability and maintainability of our code by keeping the caller of the method and the method itself as close to one another as possible

Testing Emails in ASP.NET without a mail server

Many of times it happens that we want to checkout whether the mail function is working properly without configuring the SMTP server..
Here is a simple trick to although to fullfil your need.
Follow the steps given below:
Step 1. Open the configuration file web.confing located at the root of your web application.
Step 2. Add the following stuff in it.

<system.net>
 <mailSettings>
     <smtp deliveryMethod="SpecifiedPickupDirectory">
         <specifiedPickupDirectory pickupDirectoryLocation="C:\emails\"/>
     smtp>
 mailSettings>
system.net>

things to note in the above code is specifiedPickupDirectory element which performs the task of configuring the local directory for SMTP. Second thing is pickupDirectoryLocation. This is the location on your local drive where your application keep the mail to be used by SMTP later.

So what's more remaining is testing the above settings.
write the following code in the click event of your send mail button's click event.

System.Net.Mail.MailMessage mail = new System.Net.Mail.MailMessage("fromThis@email.com",
"toThis@email.com", "subjecthere", "Testing email without smtp configuration");
System.Net.Mail.SmtpClient client = new System.Net.Mail.SmtpClient();
client.Send(mail);