Using statement vs Using Directive

Recently in a quiz, I came across a question about the “using” statement in relation with garbage collection. I was sure that using had nothing to do beyond specifying the namespace that a class used.

All I could think of was this

For eg : using System.Text;

However, a few days later, when I did a quick walkthrough of some code that was in front of me, I remembered that we use “using” within the code we write as in

using (Font font1 = new Font("Arial", 10.0f))

{

//some code related to font1

}

So I did some probing into MSDN and code project and here are the results:

What exactly do both the using’s do?

1. Using directive

First of all the using used with the namespace is called “using directive” (Many of you may know this, but I was not aware of this even after 3 yrs of coding in .NET). It does nothing more than suggesting which namespace (both user defined and system defined) is going to be used by the class.

2. Using statement

This can be a powerful tool to help in releasing memory – it specifies when the objects using the resources (for e.g. the object that uses font1 in the example above) should release them.

Have a look at this fragment of code:

 using (Font font1 = new Font("Arial", 10.0f))

{

               Console.WriteLine(font1.Name);

}

How does this block of code work?

Internally using statement calls a try and a finally block without catch. It uses IDisposable interface to free the memory allocated. The sequence is as follows:

1)      The constructor of Font1 is called i.e. (new Font("Arial", 10.0f)))

                                    |

            2) A try block with Console.WriteLine stmt is executed i.e. (Console.WriteLine(font1.Name);)

                                    |

3)The finally block disposes the memory allocated to the object font1 i.e. (font1.Dispose())

So the code essentially (that goes on within) would look like this:

private static void Main(string[] args)

{

      Font font1 = new Font ("Arial", 10.0f));

      try

      {

            Console.WriteLine(font1.Name);

      }

      finally

      {

            if (font1 != null)

            {

                  font1.Dispose();

            }

      }

 }

Hence, the using statement leaves it in the hands of the programmer to decide when memory should be freed. This would be otherwise done by the CLR.

First thing to be noted to use using statement : The class must implement IDisposable interface.

Another thing to be noted is that if any exception is thrown in step 1, then step 2 and 3 will be bypassed.

Why do we use Factory design pattern, and Spring Framework?

 Say there are three objects in real world :

•     A showroom that does some value added services(eg like adding license plate and give the finishing touch by adding varnish) for cars and scooters and uses both for sale after doing the value add.
•  Car 
• Scooter 

Now if the showroom has to do finishing for the scooter(without using either Factory Pattern or IOC) as the customer wants, it should know what kind of scooter it is going to do Value added services for i.e. the specifications of the scooter and car(like color,length and the showroom would provide the specifications and get it from the scooter factory and the car factory. So the details of the car/ scooter have to be known to the showroom. Hence, there is a strong dependency/ coupling on showroom for the both of these objects. 

If you look at it programmatically 
to create car object and scooter object from the Car class(ie the Car factory in real world) and Scooter class, the  showroom will have to know about the constructor arguments of car and scooter.

Class Showroom

{
            //say the customer feeds in the choice of vehicle for which he wants to perform value added service
            Public createObjectBasedOnDemand(string choice){

                        If(choice.Equals(“Scooter”))

                                    {Scooter s = new Scooter(length,breadth,ht,color);}

                        Else if(choice.Equals(“Car”))

                                    Car c = new Car(color,height,weight,length);

            }
}

Now firstly, we do not want the showroom to necessarily know all the details of the scooter and car as it is only going to do value added services like adding license plate and give the finishing shine by adding varnish. But in this approach the Showroom knows all the intricate details about the car like height, weight and color.

Secondly (programmatic issue), the “new” keyword is used too many times. This would mean in case another type of vehicle is added eg lorry, a new line of code will have to be added for choice lorry inside the method createObjectBasedOnDemand. This would mean that the whole code will have to be recompiled.

To do away with these 2 problems we use factory method pattern in conjunction with spring.

To solve the first problem 1(showroom knows everything about individual vehicles) we use Factory method pattern:

Step 1: We introduce an interface called Vehicle which the classes Car, Scooter, Lorry implement. The benefit of this is that we will be able to introduce any number of new vehicles that implement this interface (like motorboat, bike etc) and the showroom will not have to know about either them or the specifications of theirs. The showroom will point to the interface alone and will not know anything more than the choice of the customer i.e. the name of the vehicle the customer needs.

Public interface IVehicle{ public doSomeValueAdd();}

Public class car implements IVehicle{ public Car(string color,int ht,int wt,int len){ //some code; }

Public doSomeValueAdd(){//some code;}}

// and similar code for the other classes

Step 2: We introduce a factory class that knows what the concrete classes available. This factory class however will return only thetype Vehicle back to the customer as:

Public class Factory

{

           

            Public static IVehicle getVehicleBasedOnChoice(string choice)

            {

            IVehicle vehicle;

            If(choice.Equals(“Scooter”))

                        {vehicle = new Scooter(len,br,ht,color);}

            ElseIf(choice.Equals(“Car”))

                        {vehicle = new Car(color,ht,wt,len);}

            //some more conditions

            Return vehicle;

            }

}

Step 3: We change the code of the showroom class to reference only the factory and obtain the object of interface and do the value add

Public class Showroom

{

            Console.Writeline(“Enter the choice”);

            string choice = Console.Readline();

            IVehicle vehicle = Factory. getVehicleBasedOnChoice(choice);

            Vehicle.DoVaueAdd();

}

Using this approach the showroom is totally oblivious about what kind of vehicles are present and the specifications of the vehicle.

Solving issue 2( Enormous number of new keywords) Spring Injection

As the new keyword problem is not solved by using Factory method alone, we use the Spring framework to do the work of the factory class by means of xml files. If you have read my first article on Inversion of Control at : http://dotnetnhibernateconcepts.blogspot.in/2013/05/inversion-of-control-in-laymans-terms.html

We have spoken about a container/dealer that does work of the factory class in our example. Spring accomplishes this by xml files which contain data for example:

<objects xmlns="http://www.springframework.net">

  <object id="IVehicle" type="vehicle, someNamespace, Version=9.0.0.0, Culture=neutral, PublicKeyToken=a978a715ccadf176" singleton="true" autowire="constructor" singleton="true" />

We would then instantiate the object of type via a customized factory class that would

obtain the details of the class it is instantiating from this xml file.

More about spring and the xml files etc will be discussed in the articles yet to come J

Thanks for reading.

Inversion Of Control in layman's terms

This is a question oft asked by beginners, when they are inquisitive about why we use inversion of control and what bearing IOC has in the real world. So here I have attempted to explain the IOC with my own example:

Say there are three objects in real world :
1. A showroom that  does some value added services(eg like adding license plate and give the finishing touch by adding varnish) for cars and scooters and uses both for sale after doing the value add.
2. Scooter( which is the finish good created by Scooter Factory)
3. Car(which is the finished good created by the car factory)

Now if the showroom has to do finishing for the scooter(without using IOC), it should know what kind of scooter it is going to do Value added services for i.e. the specifications of the scooter and car(like color,length and the showroom would provide the specifications and get it from the scooter factory and the car factory. So the details of the car/ scooter have to be known to the showroom. Hence, there is a strong dependency/ coupling on showroom for the both of these objects. 

If you look at it programmatically 
to create car object and scooter object from the Car class(ie the Car factory in real world) and Scooter class, the  showroom will have to know about the constructor arguments of car and scooter.

Class Showroom{
Scooter s;
Car c;
/* See how scooter and car are instantiated by calling constructor of class Scooter and Car.
    That means, Class Showroom needs knowledge about Scooter and Car like
    ‘Which are the possible constructors of Scooter and Car?
     What should be the constructor parameters?’
     This is termed as Tight coupling between Showroom and Scooter/showroom and Car/Showroom.
*/
Public Showroom(){
s = new Scooter(color, length, width);
car = new Car(color, length, width);
}
}

Now we do not want the showroom to necessarily know all the details of the scooter and car as it is only going to do value added services like adding license plate and give the finishing shine by adding varnish. So we would rely on some other entity , say Dealer,to get the scooter and the car from the Scooter factory and Car factory and pass the goods to the showroom to do the finishing. So the control of getting the car and scooter lies in the hands of the Dealer and the showroom knows nothing about the specifications of the car and the scooter it is going to do the finishing for until the car and scooter come to it. 
In the programming world this dealer (who passes on the goods to the showroom) would be called "Container". So all the details of the scooter and car are known only to the Container/dealer who has now become the Controller, previously the showroom was the controller. Hence the name inversion of control.

If you look at this programmatically,

Class Showroom{
Scooter s;
Car c;
/* Look Object of Scooter and Car will be created by Container and provided as Constructor argument.
So, Class Showroom doesn’t need to know class Scooter and Car constructors and all.
It is loose coupling between Showroom  and Scooter/Showroom  and Car.
*/
Public Showroom(Scooter s1, Car c1){
this.s = s1;
this.c = c1;
}
}

Thus, in the above example
the classes Showroom , Car and Scooter are less coupled. This method of passing the objects through a construtor is called constructor injection.

(I originally published this answer at https://www.quora.com/Computer-Programming/How-will-you-explain-Inversion-of-Control-in-laymans-terms)