How to structure packages

[Jonathan Hartley]

On Thursday, September 8, 2011 1:29:26 AM UTC+1, Steven D'Aprano wrote:
> Steven D'Aprano wrote:
> 
> Other than that, is there any justification
> for this rule? Any Java fans want to defend this?
>
> If "one class per file", why not "one method per class" too? Why is the
> second rule any more silly than the first?


Hey. I'm not a Java fan but I'll give it a go.

One method per class is not a good idea because a class is a bunch of code that forms a coherent conceptual bundle of functionality. Often, to provide such a bundle, it requires more than one method. To split these methods across several classes would be splitting up a single coherent entity, which makes it harder to understand the purpose and identity of the entity, and more fiddly to delineate the boundary between one such entity and the next.

On the other hand, IMHO one class per file is often a good idea. Since a class is a single coherent bundle, then the natural way to split a program into files is often to divide it into these same coherent bundles. Sometimes you have two or more classes that are conceptually very tightly coupled, and it makes sense to gather them up into a single file. However, for me, this is the exception rather than the rule, so in the general case, I usually end up with code that has one class per file. It's only a rule-of-thumb though, and should be broken whenever it seems appropriate.