Breaking Down Classes Into Files

Question

I'd like to know what's considered best practice when dividing multiple classes into seperate files. I know you can have only one public class per file, and I've heard some people say it's best to have one class per file, period. But the one-class-per-file rule seems overly strict.
To give a specific example, I have a class which manages event handlers and event generators. The class receives events and delegates them to one of its registered handlers. The handlers can, in turn, spawn new events by calling the event generators, which have package access.
Currently, I have the handlers, the generators, and the public class which manages them all in one file, which I know is not good, especially since some of the handlers and some of the generators are fairly large classes in their own right. However, it would be silly (I think) to put every handler and every generator in its file, because some of them are almost trivially small, and none of them have public access. But what is the best way to break them down: Should I put the handlers all in one file, and the generators all in one file, giving me three files total? Or are there other principles that should guide me?
Thanks for any thoughts,
John

Answer 1

That's a good point. Although, as you said, it
doesn't really apply in my case. That is, if I put
all the handlers in a file called EventHandlers.java,
that should be pretty clear for me. And, in fact, it
would probably be easier to work with the classes if
they are all in one file.But what do you think about when I say reuse? Don't you think that one class per file will make it easier to reuse the classes? As it is now you have to take them all. Since you have things that are in common for them I would say that you must have interfaces, and abstract classes. Couldn't they be reused in another project? So there are benefits even in small projects. It's also better to have many files if there are several developers and your version manager doesn't allow multiple checkouts of the same file.
>
Also, you mentioned sub-packages. I'm assuming
classes in sub-packages do not have access to their
parent's package-access members. What I really would
like is to prevent any classes except the event
handlers from accessing my EventManager's generator
members. Could you solve that problem in another way? Why do they need access to the EventManager?
Are you saying I should put all the other
classes in a sub-package? I say that you should put related classes in sub-packages. Look at the package structure of the java core (can be seen in the javadoc)
/Kaj