From C++/C# to Java -- Properly structuring code with "one public type per class" rule

Question

I just started developing in Java after not having touched it since my college days. So far I've been able to remember a lot of things and read up on a whole bunch, this one is still not clear to me...

The problem I'm having is that a lot of books/examples/tutorials/SE posts focus on simpler, smaller problems where this type of question would not occur.

If you have a project with 1000's of types (classes, interfaces or both)... is the best project structure/layout convention to simply create a new file for each type? Coming from C++/C# background, that doesn't sit well with me (yet?) as I'm used to typically having one, or maybe few, files that would define interfaces used throughout the rest of the project. And small, related classes would often be implemented in one file.

As a more concrete example, I am currently refactoring an "Event" class which currently is handling 15 different event types, all in one class. The package where the class is defined also has other event-handling classes, such as readers, writers and parsers.

If I create base event class and 15 deriving classes, as each one has slightly different attributes/behaviors... these are my options:

1. 15 new files all added to the existing package - seems I'd be "polluting" that package as number of files would go from 6 to 21 and orthogonality would break.
2. Move all event classes into their own package and keep them together
3. Create one file, called "Events.java" and put all 15 classes as nested static classes of that one main class (in essence "class Events" would become just a namespace) - appears that Google does that with their protocol buffers.

Having not enough Java experience, I just can't decide which approach is an accepted standard. Is it ok to have 1000's of files in one directory? Should I create more packages? (looking at other libraries/frameworks, it appears that they keep number of packages to a minimum)

In other cases, especially when implementing a strategy pattern, i would create one public base class with a static factory method and a number of non-public classes just so I could keep them in one file. Seems I'm making these "design" choices only based on this one public type per class rule and everything time I do that, this question comes back... maybe I'm just not doing it right.

Answer 1

Having to get over the idea of "too many files" is common among programmers coming to java from other languages.

There are special cases where you might want to have, say, a static inner class that you make public (see Map.Entry, for example), but generally, you want to stick with one class (one source file) per public class.

It certainly makes sense to create sub-packages when classes can logically be sub-grouped. Don't be afraid of creating "too many" packages either.

Answer 2

I'd put all fifteen event subclasses in their own package, in their own files. Fifteen classes is not too many. I've heard of corporate applications having thousands (maybe even tens of thousands) of classes/files.

The only time I see several public types in one file is when they are constants or enums, e.g. java.sql.Types. You could alternatively define them as enums, and switch on them, but then you lose polymorphism.