79

I am relatively new to C# and each time I begin to work on a C# project (I only worked on nearly mature projects in C#) I wonder why there are no inner classes?

Maybe I don't understand their goal. To me, inner classes -- at least private inner classes -- look a lot like "inner procedures" in Pascal / Modula-2 / Ada : they allow to break down a main class in smaller parts in order to ease the understanding.

Example : here is what is see most of the time :

public class ClassA { public MethodA() { <some code> myObjectClassB.DoSomething(); // ClassB is only used by ClassA <some code> } } public class ClassB { public DoSomething() { } }

Since ClassB will be used (at least for a while) only by ClassA, my guess is that this code would be better expressed as follow :

 public class ClassA { public MethodA() { <some code> myObjectClassB.DoSomething(); // Class B is only usable by ClassA <some code> } private class ClassB { public DoSomething() { } } }

I would be glad to hear from you on this subject - Am I right?

Improve this question
1
  • 1
    Also note that you cant have extension methods in nested classes.. Commented Feb 25, 2013 at 10:45

4 Answers 4

Reset to default
82

Nested classes (probably best to avoid the word "inner" as nested classes in C# are somewhat different to inner classes in Java) can indeed be very useful.

One pattern which hasn't been mentioned is the "better enum" pattern - which can be even more flexible than the one in Java:

public abstract class MyCleverEnum { public static readonly MyCleverEnum First = new FirstCleverEnum(); public static readonly MyCleverEnum Second = new SecondCleverEnum(); // Can only be called by this type *and nested types* private MyCleverEnum() { } public abstract void SomeMethod(); public abstract void AnotherMethod(); private class FirstCleverEnum : MyCleverEnum { public override void SomeMethod() { // First-specific behaviour here } public override void AnotherMethod() { // First-specific behaviour here } } private class SecondCleverEnum : MyCleverEnum { public override void SomeMethod() { // Second-specific behaviour here } public override void AnotherMethod() { // Second-specific behaviour here } } }

We could do with some language support to do some of this automatically - and there are lots of options I haven't shown here, like not actually using a nested class for all of the values, or using the same nested class for multiple values, but giving them different constructor parameters. But basically, the fact that the nested class can call the private constructor gives a lot of power.

Improve this answer
Sign up to request clarification or add additional context in comments.

19 Comments

Very clever! But I will never use it. Software book writers and their readers (!) are often clever peoples. They think to a lot of bright things and it's cool. But software maintainers are ordinary people who didn't read Gamma/Skeet. My guest: the more it is clever, the less it is maintenable...
That's true until it becomes a recognised pattern. It's like "while ((line = streamReader.ReadLine()) != null)" looks bad to start with - side-effects in a while condition! But when it's idiomatic, you get past that smell and appreciate the conciseness.
@Sylvain: I think it's like LINQ - it adds to the maintainability when you're used to it, but looks odd at first sight. But I agree that it's not a common pattern in C# yet :(
@Jon, thanks! I think I got it now. MyCleverEnum acts as both the the holder of the enum members and the interface of each enum member, so it is more succinct than other solutions. The use of embedded classes ensures that the support classes are hidden from outside the class. The private constructor makes the class behave like a static/singleton class from outside the class but like an abstract base class from inside the class.
@supercat, You could put a using directive at the top of the file using FirstCleverEnum = MyCleverEnum.FirstCleverEnum. This can mitigate the problem, but there is no way to "export" this alias.
|
32

The Framework Design Guidelines has the best rules for using nested classes that I have found to date.

Here's a brief summary list:

  1. Do use nested types when the relationship between type and nested type is such the member-accessibility semantics are desired.

  2. Do NOT use public nested types as a logical group construct

  3. Avoid using publicly exposed nested types.

  4. Do NOT use nested types if the type is likely to be referenced outside of the containing type.

  5. Do NOT use nested types if they need to be instantiated by client code.

  6. Do NOT define a nested type as a member of an interface.

Improve this answer

4 Comments

some of these are fairly obvious (such as 4 and 5). But could you point at reasons why the other rules are recommended?
@PeterBagnall is it just me, or 6th contradicts to the accepted answer?
@jungle_mole a nested type implementing a public interface is fine and common. The nested types type should never be exposed publicly.
@Erick yep. i'd just swapped two parts of two "designs" in my head. tbh reasons for this 6th are obvious. what i was even thinking
13

You should limit the responsibilities of each class so that each one stays simple, testable and reusable. Private inner classes go against that. They contribute to the complexity of the outer class, they are not testable and they are not reusable.

Improve this answer

6 Comments

Simple, testable and reusable are very great. But what about encapsulation? When something should not be seen outside, why make it public? In my book, inner classes can make the whole thing somewhat simpler. And they are testables (with relexion) !
I would pick encapsulation as an argument against inner classes. Inner classes can access private members of their outer classes!
Your right ! Having an inner class add some sort of coupling between it and the outer class - I did not see it at first - sorry. And thanks !
I see programmers use data structures like tuples all the time instead of private classes. I would definitely argue that a private class leads to code that is easier to read and less prone to error. Arguing that it violates encapsulation is not correct. There's nothing about a private class that violates encapsulation. It's contained inside of a class and should and does have all the rights of any other member of the outer class.
As with everything, it depends. And in this case I think it depends on the specifics of the nested class. For example, if you create a dto within a parent class (e.g. to keep method signatures clean), then there's nothing to test. It isn't any different than creating private Tuples imo, just more clear. But if you create a rich nested class that have functionality, then you're going to have a bad time.
|
3

For me personally I only create private inner classes if I need to create in-process collections of an object that may require methods on them.

Otherwise, it could cause confusion for other developers working on the project to actually find these classes, as they are not very clear as to where they are.

Improve this answer

2 Comments

But since they are privates classes, other developers should not be aware of them, unless, of course, they have to maintain the outer class. Of course, this can be a problem where people are not aware of private inner classes. Thanks for your answer !
If that confused my developers I would get new developers.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.