What does this do for me?

Question

I am working on a “curriculum” and use the Code Rush refactoring tool with my training. With the latest Code Rush update, he recommended implementing IDisposable for my programs. I know that MSDN is talking about IDisposable, and I have a real basic understanding of what it does, but since I don’t know all the consequences of its implementation, I ignored this recommendation. Today I decided to learn more about this and agreed with the recommendation.

This is what he added to my program.

class Program : IDisposable { static Service _proxy; public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } protected virtual void Dispose(bool disposing) { if (disposing) if (_proxy != null) { _proxy.Dispose(); _proxy = null; } } ~Program() { Dispose(false); } 

So my questions are these. Does this do all I need to get the advantage of IDisposable, or do I need to do something in the code to make it work? I put breaks on it and never reached it through the debugger so it was not needed, or I did not use it the way it was intended. Can someone shed some light on what this does for me or how should I use it so that it does something for me?

Answer 1

In this case, CodeRush offers you to implement IDisposable , because your class encapsulates the IDisposable resource (it sees _proxy , although this is not entirely good, since it is static). The Rush code believes that there is a type that you are using that needs to be explicitly cleared, but you do not provide a way to do this through your class.

At the same time, IDisposable complicated, and this is one case when the generated code is not really a good implementation (even if _proxy is an instance variable). In this case, I would recommend not using a destructor. This will cause performance problems in the GC, and in this case will not help with security, since the encapsulated resource should handle the case when you forgot to call Dispose() for you. For more information, see my IDisposable series and, in particular, the encapsulation of the IDisposable class .

In addition, this class should not implement IDisposable (unless there is another reason for this), given the code above, since the _proxy resource _proxy static . Removing a static resource from an instance can cause problems, at least in the general case. (In this case, this is obviously not problematic, but this is not a good practice ...) Usually a static variable has a completely different lifetime than a member of the instance, so automatic control of it would be inappropriate.

Answer 2

In a correctly written program at any given time for each object that can have a meaningful implementation of IDisposable, there will be some entity that is responsible for ensuring that IDisposable.Dispose is called on this object sometime between the last "real use" of this instance and its final abandonment. In general, if a Foo object contains references to objects that implement IDisposable, at least one of the following scenarios must be applied:

• Some other objects will also contain a link, at least as long as Foo needs it, and takes care of calling Dispose on it, so Foo should let another object take care of Dispose.
• The object containing the link will be the last thing to use the IDisposable object; if Foo doesn't call Dispose, there will be nothing else. In this case, Foo must ensure that this other Dispose method is called as soon as it (Foo) is no longer needed, and before its failure. The most idiomatic way to handle this is for Foo to implement IDisposable.Dispose and for its Dispose method to call Dispose on IDisposable objects to which it contains the latest useful links.

There are some scenarios where the class developer may not know if his class will contain the last useful reference to the IDisposable object. In some cases, this problem can be solved by using a class constructor that indicates whether the IDisposable will be passed to the provided or given constructor. In other cases, you may need to use wrappers to count links or other complex methods.