The example you gave is actually fine in my opinion. You are declaring inner classes, so it is perfectly sensible to keep them in the same file. The only way around this would be to make your
Items class a partial class and split it over multiple files. I'd consider this bad practice. My general policy for nested classes is that they should be small and private. There are two exceptions to this:
- you are designing a class cluster (more common in objective-c), thus it may be sensible to use the partial class approach
- you need an enum that is only used with the public API of the parent class. In this case I prefer having an public enum declared inside the parent class instead of polluting my namespace. The enum being an "inner enum" effectively results in giving it a well defined scope.
If you word the question a little differently and ask about "Should I put each namespace-level class into its own file" then my answer would be "yes".
When designing classes we respect the Single Responsibility Principle. Reading code becomes a lot easier if its shape follows its semantics, hence splitting files by class is sensible.
From a mechanical point of view, having a file per class has several advantages. You can open multiple classes at the same time in different windows. This is especially important since no serious developer works with less than two screens. Being able to have more context in front of my head means I can keep more context in my head. (Most IDE's will allow you to open the same file twice, but I find this awkward).
The next important aspect is source control and merging. By keeping your classes separate, you avoid a lot of hassle when changes to the same file are made because separate classes need to be changed.