Re: Aspect questions?
Novice wrote:
I actually split my Common project the other day into two parts. I left
only the code that I consider polished and (more or less) correct in
Common and moved all the stuff that is still crude and needs improving to
a new project called Common Candidate. The latter is far bigger!
But Common itself contains 9 classes in package com.novice.common, 8
classes in package com.novice.common.lookups, 3 classes in
com.novice.common.menus, 2 classes in com.novice.common.prefs, and 18
classes in com.novice.common.utilities.
The number isn't what's important. It's how related the types (not just
classes - you had better gosh-darned well have some interfaces in there!) It's
the relatedness of the types. Types in the same package are closely related to
each other. Those in different packages aren't. It's how related the types
should be that determines the designer's choice of which package holds them.
The resource bundles for each package are in separate packages that have
Resources as the last qualifier, e.g.
com.novice.common.utilities.Resources. I have the impression, perhaps
The usual (but not universal) convention is to name packages in all lower-case
with no underscores. That name looks like 'Resources' should be a type, not a
package name element.
Putting resources in a different package from the consuming type makes it
harder for the consumer to locate the resource, but it's not really wrong.
mistaken, that resource bundles are supposed to be in different packages
than the classes they support.I don't remember where I got that; I think
it was a newsgroup post a few years ago but it could have been in one of
the online magazines....
There's no real rule like that. You sure have a lot of vague, half- (not to
say mis-) remembered rules you try to live by without understanding.
Why don't you abandon all these rules and substitute thought about the
consequences of choices, and whether those consequences suit your purpose?
I have no idea if this is a reasonable approach. Maybe this should all be
You tell us. What are the consequences? Do you want those consequences?
I can tell you one. If you use something like 'Class#getResource[asStream]()'
you have to be more careful specifying the resource location with a resource
in a different package from the class represented by the instance making the
call. Not that that is bad, but it's a consequence.
simplified so that all of those common classes and enums and resource
bundles are in one package together. Or just two, one for classes and
enums and the other for resource bundles.
Why do you call that "simplified"? That seems like a recipe for an unholy mess.
Again, use the degree of relatedness to determine package co-residence.
Everything in the Common project is something I use regularly in various
projects or that I expect to use regularly.
The Commons Candidate project has quite a bit more code than the Common
project and is organized the same way with the same package names (and
maybe an additional package or two where none of the members are ready
for the Common project.) Some of the members of that project don't belong
there because they are just snippets that I've downloaded for learning
purposes or simple sandbox code where I'm trying something out. It needs
to be moved elsewhere but that's not a priority for me right now. But the
bulk of it has the potential to go to the Common project as something I'd
use regularly.
I'd like to start the process of doing things correctly with my current
project and Common so anything you can tell me about organizing things
would be appreciated.
Did you read the tutorial link?
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg