Pete's Weblog

The Blog Formerly Known as Fun with WinForms

  Home  |   Contact  |   Syndication    |   Login
  14 Posts | 0 Stories | 37 Comments | 100 Trackbacks

News

Archives

Post Categories

.NET Programming

Software

Weblogs

We all know about resource management in .NET (and Windows Form in particular). I'm talking about using, IDisposable, etc. These constructs work well when you own all the objects that you keep references to, as you simply dispose of each of them from your own Dispose method.

But what if you have an object that wraps another object (similar to the decorator pattern)? A Decorator must contain a reference to a ConcreteComponent, but what happens when the ConcreteComponent must be Disposed? Surely we would want Decorator's lifetime to be tied to that of ConcreteComponent? How does Decorator get disposed? There wouldn't be a problem if we could guarantee that Dispose would be called on Decorator, but what if we want to be able to remove the Decorator and keep the ConcreteComponent alive?

If we had a "Dispose" event, Decorator could just handle it and dispose of itself when necessary. But we don't. Why not -- we have events for everything else don't we?

As a more concrete example, consider my recent posting about Tablet PC support. It's quite easy to derive from Panel and add Inking to it, but it's not so easy to add that support from outside the class. In order to do this you could write a separate class (which will contain the InkOverlay) and pass a Panel object to it's constructor (like in decorator). The problem here is that, from my new class I have no way of knowing when Panel has been disposed of -- which would be nice as the InkOverlay object implements IDisposable itself.

posted on Monday, October 20, 2003 12:32 PM