C# – Are nested classes under-rated

cdesign

I'm not trying to say I know something everyone else doesn't but I've been solving more and more designs with the use of nested classes, so I'm curious to get a feeling for the acceptablilty of using this seemingly rarely used design mechanism.

This leads me to the question: am I going down an inherintly bad path for reasons I'll discover when they come back to bite me, or are nested classes maybe something that are underrated?

Here are two examples I just used them for: https://gist.github.com/3975581 – the first helped me keep tightly releated heirarchical things together, the second let me give access to protected members to workers…

Best Answer

I would not call this a "rarely used design mechanism" - at least, not universally: although there are shops where some contributors may frown upon using nested classes, this is not an obscure feature at all.

Although the existence of classes with assembly visibility and the introduction of lambdas has significantly reduced the need for nested classes^*, they remain a valid design choice. Although there is some overlap with internal classes inside a namespace, the nested classes feature is unique in letting you hide a class entirely inside another class.

^* The use of a similar feature in Java is much higher, because other alternatives available in C# are not there in Java.

Related Solutions

C# – Event Subscription from Nested Classes

Yes, it is OK and it is a good way of hiding the details of your inner events as well as having one class to connect your event listeners to, instead of several one. It does not mean that having multiple events in multiple classes is bad - far from it - just that it helps in increasing the comprehension of your code if all events related to a particular business domain are in the same "place", although the real inner work is done in "child" classes.

There even is a name for it: event bubbling. You may be interested in reading the MSDN article on that subject.

C# – Nested Classes or Namespace

Well, currently the main difference is a namespace is designed to be augmented in separate files. If you try to add a new nested class to a class, you get:

test1.cpp:3:7: error: redefinition of ‘class NamespaceClass’

However, it only works that way because it was defined that way. It wouldn't be that difficult to rework the compiler to append to a class in certain ways when it sees what is now a redefinition.

The reason they don't is that a namespace and a class are conceptually two different things, used for different reasons. A class is meant to be instantiated, and is used to create strong cohesion between a data structure and its associated methods. A namespace is meant to loosely gather modules to make it easier to share groups of several files without causing naming clashes.

Yes, you can approximate the behavior of one using the other, but that doesn't make them the same. If you used a redefinition-allowed class instead of namespaces, you would have problems like:

Having to look through all header files using that class to get its entire definition, including determining if it's instantiable or not.
Wanting to use a name that denotes its purpose as a namespace, like StdNamespace instead of just std.
Needing some sort of syntax to clue you in when you do accidentally redefine a class when the compiler just thinks you mean to augment it like a namespace.

When you add up all the special cases you would need to handle to make it truly follow the open-closed principle, you may as well just call it a namespace.

Best Answer

Related Solutions

C# – Event Subscription from Nested Classes

C# – Nested Classes or Namespace

Related Topic