Martin Gregorie<martin@address-in-sig.invalid> wrote in
news:jih660$s5$1@localhost.localdomain:
On Mon, 27 Feb 2012 05:20:48 +0000, Novice wrote:
I've really struggled with this. I have things set up a certain way
now but I'm constantly second-guessing myself and wondering if its
the best way to do things.
In that case, leave the package structure as it is unless you find
problems with it. In fact I'd go so far as to say don't subdivide it
into separate packages unless there's a really good reason for doing
so. Once you've written a few programs, particularly if most of the
classes in them require access to at least one of your common classes
it becomes a real pain to repartition them between packages because
doing so will cost significant effort to go through all your
application classes and adjusting their 'import' statements.
Most common classes tend to be quite small and you probably won't have
all that many of them: my collection has evolved over the last 10
years and stand at 21 classes which contain 5800 lines of source
including the Javadocs documentation comments, so the collection would
have to grow by at least 50% before I'd consider splitting up that
package.
I'm surprised that your common class is so small in terms of number of
classes, especially after 10 years! I would have thought you'd have
written many more by now....
I've got 40 classes in mine already and those are just the ones I
consider more-or-less finished. I've got many more in my CommonCandidates
project where I store the ones that are still just half-baked (or
less!).I'm regularly thinking of new ones to add....
and down, because the list is long.
I think I would have split before 40.