Clever Geek Handbook

Is it possible to implement the abstract class DisposeBase?

Is there a catch or hidden issue when using the base class DisposableBase instead of re-encoding the Dispose template for each class?

Why doesn't everyone use such an appropriate class?

edits

  • I naturally only meant classes that implement IDisposable

  • I know it uses the inheritance option, but I am willing to pay the price (at least when I can and it doesn't hurt me).

  • When I can pin a class, I do it, but I have some cases where I want the base of the inheritance hierarchy to be disposable.

+1


source to share


3 answers


You don't need to implement Dispose () for every class - only those that have deterministic cleanup. Re a One-time base class, I'm not entirely sure if it provides a lot - IDisposable

not a complicated interface. Most of the time this can be useful if you are working with unmanaged resources and want a finalizer, but even then it's not a lot of code.

Personally, I wouldn't bother with such a base class. In particular, inheritance (in a world with one inheritance) gets very fast. What's more, overriding a method is not much different from simply providing a public Dispose () method.



Again: you only need a finalizer, etc. if you are handling unmanaged objects.

If I had many such (unmanaged resources) I could see if I can get PostSharp to get the job done for me. I don't know if it already exists, but it is possible to create an aspect that handles (specifically) a finalizer, etc. Who knows...

+2


source


Well, it uses one inheritance option to describe one aspect of your class - it's not ideal, IMO. It would be interesting to try to do something with composition, where you have a reference to DisposableHelper and the IDisposable implementation just calls helper.Dispose, which has the rest of the template logic in it, and can call back to your code via the delegate callback. Hmm. Subclasses could subscribe to the protected Disposing event to register "I need to do something" ... it might be worth looking at for a while.



Personally, I don't implement IDisposable too often to make it a problem, and when I do I usually close my classes, so half the stuff in the template becomes a non-problem.

+2


source


As Mark Gravell said, you only need a finalizer if you are working with unmanaged objects. Implementing an unnecessary finalizer in a base class is a bad idea, for the reasons in section 1.1.4 Dispose, Finalization and Resource Management of the recommendation:

There is a real cost associated with instances with finalizers, both performance and code complexity point of view .... Finalization increases the cost and lifespan of your objects in every final object must be placed on a special finalizer registration queue upon allocation, essentially creating additional a pointer size field to reference your object. In addition, objects in this queue are received during GC, processed and ultimately another queue that the GC uses to execute finalizers. An increase in the number of finalized objects is directly correlated with a larger number of objects being promoted to higher generations, and an increase in the time spent walking GC queues, moving pointers around, and executing finalizers. Besides,By keeping the state of objects around for longer, you tend to use memory for a longer period of time, resulting in an increase in the working set.

If you are using SafeHandle (and related classes), it is unlikely that any classes that derive from DisposableBase should ever be completed.

+1


source






More articles:


All Articles