Yeah, “may derive” was the correct interpretation. Good explanation – it’s quite clear now.

Yes, the class is intended to be inherited (as will be illustrated in my follow-up post). But, in an of itself that should not clash with any OO design concepts, and neither does any base class determine the defining feature of its derived classes. When we talk OO, we say that derived classes “specialize” the type of the base class, that they are “more specialized” than the base, or that the base class is “more general” or “less specific” than the derived classes. As such, the base class can at most determine some characteristics of the derived class. There is in principle no limit on how the derived class can extend the base.

Nevertheless your alarm is quite rightly placed. In this particular case one has to consider the derived class in detail, before deciding to inherit from Disposable. If there is contention in that the class may also rightly derive from a different base, then one has done well to pause.

If Disposable was at all difficult to implement or widely used, I’m sure the framework would have had its own implementation. But, while there are no doubt valid reasons for the framework to only provide the IDisposable interface, that does not imply that we MUST always implement the interface from scratch.

To conclude (and hopefully satisfy your query) – this kind of abstract base class is probably not something that you’d ship as part of a public library, but can be a very useful addition to an internal framework, where you are at once the publisher and consumer of the class. In such a scenario you are free to both inherit the base functionality on the occasions where you have classes that are in themselves of a fairly primitive nature (does not inherit base functionality – ironically these are usually the ones where you’d want IDisposable functionality), or alternatively simply use the code as a template for the manual implementation of the IDisposable interface (i.e. for illustration purposes).

Just an afterthought about the possible intent of your question… I would say classes “may” derive from it, not that classes “should” derive from it (i.e. don’t simply make all classes disposable). Also, classes deriving from it (and for that matter any classes implementing IDisposable) shouldn’t necessarily add a finalizer unless it’s specifically required by the state or owned objects of that class. Finally, when a class does implement IDisposable or inherit this base, if it defines a finalizer it should be sealed, as further consumers will not necessarily be aware of the finalizer and may add additional finalizers into the hierarchy, which would start to make the derived object very expensive to use.

Interesting post and I like the website. Perhaps this is a silly question, but what is the purpose of the Disposable class – i.e. is it for illustration purposes, or should classes derive from it? In the latter case, would it not clash with OO design concepts in many cases – as you can’t have multiple inheritance, you’re basically stating that the defining feature of the derived class is that it’s disposable?

Thanks