Re: Aspect questions?
Arne Vajh??j wrote:
Lew wrote:
Arne Vajh??j wrote:
Novice wrote:
I'm currently grouping mine on a more-or-less functional basis. If the
class is essentially just a table lookup or enum, then it goes in the
com.novice.common.lookups package. If it is a utility, it goes into
com.novice.common.utilities. And so forth.
That is general question not specific to logging or AOP.
You need a good structure of your classes and source code.
A key factor in the decision between com.novice.common and
com.novice.common.xxxx must be the number of classes.
Do you have so many classes that it makes sense to split up?
That threshold would be one.
Every type should be in a package. Every type should be in its
appropriate package, irrespective of how many types (not just classes!)
you have. A model-view-presenter program could, and probably should,
have three packages with just the five or six types (including the three
concrete classes but not the test code, which would add more).
Nobody is suggesting classes should not be in package.
If there is a good package structure given by the design, then
that should be used.
But the question was about com.novice.common vs
com.novice.common.lookups + com.novice.common.utilities.
I would let the number of classes decide that one.
And the critical number is bigger than one.
I disagree, with respect for your position.
Not that the number will be greater than one, but that it's a motivator for
the distinctions.
The difference between 'com.novice.common' and 'com.novice.common.lookups' and
'com.novice.common.utilities' should take no note of how many types (NOT just
classes!) would go in each package, but whether those in the first are merely
"common", those in the second are common to "lookups", and those in the third
are common "utilities".
If you have a hard time semantically distinguishing one package from another,
then you shouldn't have more than one package. Regardless of the number of
types in it.
A package is a namespace, not some finite-sized bucket that holds some
particular number range of items. Its purpose is to semantically group related
types together. What determines co-residence in a package is semantic
similarity, not quantity.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg