Is having a fine-grained package structure a good or a bad thing?

Question

I recently looked at a Java application which had a very fine-grained package structure. Many packages only contained one or two classes and many sub packages. Also many packages contained more sub packages than actual classes.

Is this a good or a bad thing?

Answer 1

IMO, it is a bad thing, though not a real show-stopper in terms of maintainability.

The disadvantages are that it makes classes harder to find, and that it makes the package names more verbose. The former applies more when you are not using an IDE.

It could be argued that it helps modularization in conjunction with "package private" scoping. But conversely, you could also argue that over-packagization actually does the opposite; i.e. forcing you to use public where you wouldn't have had to if you'd been less fine-grained / pedantic.

Answer 2

The actual number of types that end up in one particular package is not that important. It is how you arrive at your package structure.

Things like abstraction ("what" instead of "how", essentially "public" API), coupling (the degree of how dependent a package is on other packages) and cohesion (how interrelated is the functionality in one package) are more important.

Some guidelines for package design (mostly from Uncle Bob) are for example:

• Packages should form reusable and releasable modules
• Packages should be focussed for good reusability
• Avoid cyclic dependencies between packages
• Packages should depend only on packages that change less often
• The abstraction of a package should be in proportion to how often it changes

Do not try to flesh out an entire package structure from scratch (You Are Not Going To Need It). Instead let it evolve and refactor often. Look at the import section of your Java sources for inspiration on moving types around. Don't be distracted by packages that contain only one or a few types.