Comments from co-workers I was talking with about this thread.
Note: forwarded message attached.
Was this a post to the Atlanta Users Group? Anyway, without going into great detail, here are a few suggestions based on popular convention.
First, I don't know of any hard rule that dictates the optimum package structure for any given Java application. These decisions are solely up to the development team. Sounds like this lack of rigidity has Lee a little overwhelmed. Not to worry, though. There are some widely used conventions that may help lead him to decisions he'll feel comfortable with.
Regarding quantity of classes per package, there is no simple rule. One class per package is probably too few. Putting all classes into a single package is, in most cases, too many. The balance lies somewhere in between, and is more a factor of the team's development methodology than of any written rule. Just be sensible. Think about what it would take to maintain the code and who would be doing it. Always keep the audience in mind. You have failed if your decisions make sense to the Java community at large but not to the people who will be maintaining your code. So don't base your design solely on popular convention. That said, a dozen or so classes per package works as a heuristic for me.
More important than the number of classes per package, though, is the organization of the packages. You may have 30 classes that logically belong together, that should be packaged together. Distributing them out among several packages, solely for the sake of reducing the number of classes per package, may compromise your design at an OO level. So I would argue that it is better to establish an intuitive package structure than to restrict the number of classes per package.
A word about "David"'s comments on packaging and naming. I would agree with his philosophy on organization of code, but not with his suggestions about naming. In my experience, Sun's recommendations regarding package naming/grouping are widely accepted, and seem to be the defacto standard. See the "Packages" chapter in the Java Language Specification:
ftp://ftp.javasoft.com/docs/specs/langspec-2.0.pdf
Basically, package hierarchies should begin with a domain-scope package, followed by an organization-scope package, followed by an application-scope package, followed by component-scope packages. Here are some examples:
com.mycompany.myapplication.mycomponent
com.sun.java.jag.scrabble
com.wellfound.messaging.util
com.wellfound.messaging.db
com.wellfound.portal.control
This approach is intuitive, self-documenting, and fully describes the context within which the code operates. It facilitates the "productizing" of components and is understood and accepted by the widest audience.
I would recommend reading through Sun's Java Lanuage Spec to get familiar with their recommendations. Then read through some of the better known Java coding guides (such as Doug Lea's). Soak all that information in and use it to make informed decisions about your own environment. And don't follow guidelines rigidly or blindly. Often it's more appropriate to bend (or break) the rules! Either way, make sure you can always justify the approach.
Hope that helps.
Marc
---------- Original Message ----------------------------------
From: Eric Ballou <iknowbea@yahoo.com>
Date: Mon, 3 Nov 2003 22:13:30 -0800 (PST)
Since it seems to have some relevence to our conversation today, I thought I would pass this on.
Eric
Note: forwarded message attached.
---------------------------------
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard