Effective C # Principle 18: Implementing standard processing (Dispose) patterns

As we have discussed, it is important to deal with an object that occupies an unmanaged resource. It is time to discuss how to write code to manage the non-memory resources that these classes occupy. A standard model is the use of. NET Framework provides methods to handle non-memory resources. Your users also want you to follow this standard pattern. That is, by implementing the IDisposable interface to release unmanaged resources, of course, when the user remembers to call it, but if the user forgets, the destructor is also passively executed. It works with the garbage collector to ensure that, at some point, your objects are only subject to performance losses due to the destructor. This is a good way to manage unmanaged resources, so it is necessary to understand it thoroughly.

The base class at the top level in a class inheritance relationship should implement the IDisposable interface to free resources. This type should also add a destructor as the last passive mechanism. Both methods should be a virtual method to free the resource, so that its derived classes can overload the function to free their own resources. A derived class overloads this function only if it needs to free its own resources, and must remember to invoke the method of the base class.

At first, if your class uses a non-memory resource, you must have a destructor. You can't expect your users to always remember to call the Dispose method, otherwise you'll lose some resources when they forget. This may be because they did not call dispose of the error, but you also have the responsibility. The only way to ensure that a non-memory resource can be properly released is to create a destructor. So, add a destructor!

When the garbage collector runs, it removes the garbage object that is not destructor directly from memory. Other objects with destructors remain in memory. These objects are added to a destructor queue, and the garbage collector will start a thread specifically to deconstruct the objects. After the destructor thread completes its work, the garbage objects can be removed from memory. That is, the objects that need to be refactored are longer in memory than the objects that do not need to be destructor. But you have no choice. If you are using this passive mode, when your type occupies unmanaged resources, you must write a destructor. But at the moment you don't have to worry about performance, the next step is to make it easier for your users and avoid the loss of performance due to the destructor.

Implementing the IDisposable interface is a standard mode to tell the user and the time system: your object occupies resources and must be released in time. The IDisposable interface has only one method:

public interface IDisposable
{
　 void Dispose( );
}

Implementing the IDisposable.Dispose () method is responsible for completing the following tasks:

1, the perception of all unmanaged resources.

2, aware of all the managed resources (including uninstall some events).

3, set a secure tag to identify the object has been processed. If any method is invoked on an object that has already been processed, you can examine the tag and throw a objectdisposed exception.

4, to prevent the destructor. You want to call GC. SuppressFinalize (this) to complete the final work.