(2003 to 2005)

110 Uses for Nested Classes in .NET

Tue Nov 16 17:25:00 UTC+1100 2004


Shawn has the coolest blog. Minimalist, low-noise, quality, and always funny content. I just read his reasons you might use nested classes.

I would have sent this offline (via SMTP, about as 'offline' as I get these days) except I'm on a workstation with no email client while I watch chkdsk chug away on my other machine.

So, since I have a spare FOUR HOURS* I thought I'd mention number 110:

110: Exposing public interfaces via private implementations.

Prototypical example: System.Collections.Hashtable.Synchronized( .. )

That method returns Hashtable. But Hashtable is a non-sealed public class which is just basically an implementation impaired public interface. What gets returned from the Synchronised(..) method is typically “more“ than Hashtable. “More“ in the sense of implementation inheritance. What is returned *is* a Hashtable, but it's also *more than* a Hashtable because it also supports synchronisation. ( I'm being a bit sloppy there, clearly synchronisation is something that the Hashtable interface actually does cater for, it's just that the method of implementing that support can be deferred, which is what this is all about )

That's another pretty good example of a place where you might like to use a private nested class. To avoid complexity of the public API and to avoid complex specialization of the 'standard' Hashtable implementation. I.e. in the normal course of events, the Hashtable just does it's thing with no regard for synchronisation concerns and simply implements IsSynchronized as return false. Then all complexity ( and expense! ) of synchronisation can be deferred to the private wrapper derived from Hashtable ( managing complexity ), but at the same time the class definition of the synchronised wrapper need not be part of the standard public ( nor internal ) API ( reducing complexity ). Such an implementation leaves you in a position where you can avoid an interlocked compare on every public call to see if you should be synced or not, on one hand it sounds like it might be a performance hack, but on the other hand it sounds like a pretty decent way to keep code out of your code path ( less complex == good ).

I think it's probably the best example of why you might use a private nested classes.

( I also nest private flags / enum definitions that are used to represent internal state. )

In short, I think there are cases where nested classes can help you manage complexity. Often in the case of managing public API complexity while exploiting implementation inheritance, and also too in simply managing implementation complexity ( i.e. putting functionality where it belongs, ala: functional cohesion. ) I can see why you might be inclined to be cautious of it though, because used inappropriately nested classes can actually significantly increase complexity, because you lose encapsulation of the 'containing' class. ( assuming there is some definition of encapsulation in OO that allows for the possibility of nested classes! ;)


p.s. “Parameterised Properties“ are EVIL!

p.p.s. Public nested classes are almost certainly a bad idea. I can't think of many reasons you'd want to do that, apart from deliberately ruining encapsulation for some ungodly reason and at the expense of increased public API complexity..

* Might not be four hours. Batteries not included. This statement does not reflect the views of my company.

Copyright © 2003-2005 John Elliot