Deconstruction in C # [translation]

The Deconstruction in C #

Introduction




In the Enterprise application development world, performance, flexibility and security are the most important. I started my career as a VC + + programmer, and on a fine morning I was transferred to the Web Development department. Like every C + + programmer, I am also frustrated. I think every one like Tom,dick or Harry can be programmed with HTML. However, I soon discovered that the real challenge was to produce high-performance, flexible and reliable applications. To sum up, the web environment loosely coupled, regardless of the boundaries of the nature will make you forever fascinated.

In order to make high-performance flexible applications, using your resources in the most optimized way is critical. One trick is to use your resources as late as possible and release it as soon as you use it. My intention here is to describe the object cleanup mechanism in C #.

Deconstruction device

We know that the ' destructor ' is used to clear the case of the class. When we use the destructor in C #, we must keep the following points in mind:

A class can have only one destructor.
The destructor cannot be inherited or overloaded.
The destructor cannot be invoked. They are invoked automatically (by the compiler).
The destructor cannot be decorated or parameterized.
The following is a declaration of the class MyClass destructor:

　

~ MyClass ()
{
Cleaning up code goes here
}

　

Programmers cannot control when the destructor will be executed because it is determined by the garbage collector. The garbage collector checks for objects that are not used by the application. It considers these conditions to be clear and to reclaim their memory. The destructor is also invoked when the program exits. The scene that occurs behind the destructor when it executes is the Object.Finalize method that the destructor calls the object base class implicitly. So the above destructor code is implicitly translated into:

　

protected override void Finalize ()
{
Try
{
Cleaning up.
}
Finally
{
Base. Finalize ();
}
}

Now, let's look at an example of how a destructor is invoked. We have three classes of a,b and C. b derives from a,c derived from B. Each class has its own constructor deconstruction. In the main function of the class app, we create the object of C.

　

Using System;
Class A
{
Public A ()
{
Console.WriteLine ("Creating A");
}
~a ()
{
Console.WriteLine ("Destroying A");
}
}

Class B:a
{
Public B ()
{
Console.WriteLine ("Creating B");
}
~b ()
{
Console.WriteLine ("Destroying B");
}

}
Class C:b
{
Public C ()
{
Console.WriteLine ("Creating C");
}

~c ()
{
Console.WriteLine ("Destroying C");
}
}
Class APP
{
public static void Main ()
{
C c=new C ();
Console.WriteLine ("Object Created");
Console.WriteLine ("Press ENTER to Destroy it");
Console.ReadLine ();
C=null;
Gc. Collect ();
Console.read ();
}
}

As we expected, the constructor for the base class will be executed and the program will wait for the user to press ' enter '. When this happens, we set the object of Class C to null. But the destructor is not executed.!!?? As we have said, programmers cannot control when the destructor is executed because it is determined by the garbage collector. But the destructor is invoked when the program exits. You can check this by redirecting the o/p of the program to a text file. I'm going to output it here. Notice that the base class's destructor is invoked because it is in the back base. Finalize () was invoked.

　

Creating A
Creating B
Creating C
Object Created
Press ENTER to Destroy it
Destroying C
Destroying B
Destroying A
　
So, what do you do if you want to call the destructor once you've finished using the object? There are two methods:

Call the garbage collector to clean up.

Implement the IDisposable Dispose method.



Call garbage collector



You can force the garbage collector to clean up memory by calling the Gc.collect method, but in most cases this should be avoided because it can cause performance problems. In the above program, you remove the comment at Gc.collect (). Compile and run it. Now you can see that the destructor was executed in the console.

　

Implement IDisposable interface

　

The IDisposable interface includes only one public method, which is declared as void Dispose (). We can implement this method to close or release unmanaged resources such as files, streams, and handles that are controlled by class cases that implement this interface. This method is used as a resource release for all task union objects. When this method is implemented, the object must seek to ensure that all of the resources that are owned are also freed from the resources associated with the inheritance structure (cannot be grasped or turned out).

　

Class Myclass:idisposable
{
public void Dispose ()
{
Implementation
}
}



When we implement the IDisposable interface, we need rules to ensure that dispose is called appropriately.



Joint use of the destructor and IDisposable interface



public class Myclass:idisposable
{
private bool Isdisposed=false;
public void Dispose ()
{
Dispose (TRUE);
Gc. Supressfinalize (this);
}
protected void Dispose (bool diposing)
{
if (! isdisposed)
{
if (disposing)
{
Clean up Managed resources
}
Clean Up Unmanaged Resources
}
Isdisposed=true;
}
~myclass ()
{
Dispose (FALSE);
}
}

The Dispose (bool) is overloaded here for cleanup, and all cleanup code is written only in this method. This method is invoked by both the destructor and the IDisposable.Dispose (). We should note that Dispose (BOOL) is not invoked anywhere except in the IDisposable.Dispose () destructor.

When a client invokes IDisposable.Dispose (), the customer deliberately wants to clean up the managed and unmanaged resources, and thus completes the cleanup work. One thing you should be aware of is that we call Gc.supressfinalize (this) immediately after we clean up our resources. This method notifies the garbage collector that it does not need to invoke the destructor because we have done the cleanup.

Note The above example, the destructor uses parameter false to invoke Dispose. Here, we are sure that the garbage collector collects the managed resources. We only do cleanup of unmanaged resources.



Conclusion



Even so, we spend some time implementing the IDisposable interface, what if the customer can't call them properly? There is a cool solution to this C #. ' Using ' code block. It looks like this:

using (MyClass objcls =new MyClass ())
{

}
　
The MyClass Idispose.dispose () is executed when the control exits from the using block through a successful run to the end or throws an exception. Remember that the object you have shown must implement the System.IDisposable interface. The using statement defines a range of which objects will be purged.