Re: Aspect questions?
Novice wrote:
Lew wrote:
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.
Then I'm definitely bundling things incorrectly. The classes in my
package are not typically closely related. As for interfaces, I do have
If you have a package called "miscellaneous", the types are related by virtue
of having no relationship to each other or anything else. "Related" is up to
you to define.
some but now you've got me worried that I'm not using as many as I
should. It's entirely possible that I write classes when I should be
Relax.
writing interfaces. Another beginner mistake brought on by the helter-
skelter way I've learned Java....
Relax.
Interfaces are a promise. Classes are a way to keep that promise.
It's entirely possible to write a program without creating any new interfaces.
It's likely that any program you write will have some classes that do not
implement new custom interfaces.
Interfaces are a tool. You're panicking as a carpenter would were they
freaking out that they weren't using their ratchet wrench often enough.
To which I can only say, WTF?
Why don't you just learn what interfaces are and stop panicking?
I really need to review some of the fundamentals! But then I suppose
we've already established that over the last few days....
Interfaces are to specify and be clear what's supposed to happen. Consider the
Java standard 'java.util.List<E>' interface. It promises certain methods, such
as 'add(E element)', for example. It does not promise that the underlying
implementation will have an array, or fast insertion, or any other particular
about how it does the 'add()', only that it can and will do it.
Implementations of 'List<E>' include 'ArrayList<E>' and 'TreeList<E>'. Why
don't you take a break and read the Javadocs for these three types?
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.
I'd like to clarify what you mean by "type". (And I'm not saying this is
a usage that you invented; I have seen it in other places.) I tend to
read "type" as a synonym for "class" but I'm getting the impression now
that you mean classes, enums, interfaces, etc. In other words, classes,
enums, and interfaces are _all_ types in the sense that you are using the
word. Is that right?
First of all, enums *are* classes!
Second, for God's sake, man! Use a search engine once in a while!
<http://lmgtfy.com/?q=what+is+a+type+in+computer+programming>
Types are anything that classify a variable to the compiler, so yes,
interfaces and classes. Also primitive types. Also arrays.
Any classification of a variable. This is a very fundamental concept to
computer programming, and present in every computer language in one way or
another. "Type" is right up there with "operator" and "variable", "literal",
"integer".
I really wish you'd read the tutorial:
<http://docs.oracle.com/javase/tutorial/java/nutsandbolts/index.html>
"... basic data types (primitive types, character strings, and arrays), ..."
<http://docs.oracle.com/javase/tutorial/java/nutsandbolts/datatypes.html>
"The Java programming language is statically-typed, which means that all
variables must first be declared before they can be used. This involves
stating the variable's type and name, ..."
I've noticed that the Java Search in Eclipse lets you search for types,
packages, fields, methods and constructors but doesn't give you an option
for class (or enum). But if I select Type and look for a specific class
or enum or interface, it will find them.
Because those are types, so your reasoning is sound to this degree.
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.
I have no objection to putting the resources in the same packages as the
classes they are supporting. As I said, I was just doing something that I
saw recommended somewhere. And I may just have misinterpreted the intent
of that suggestion as I have other things. If there's no good reason to
keep the resources separate, I'm inclined to move them into the packages
of the classes they support.
If you saw a recommendation somewhere to jump off a bridge, would you "just do
it"?
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?
That's an excellent suggestion and one I've been thinking of for some
time! It's just a matter of isolating which things need to be abandoned.
I don't want to throw out the baby with the bathwater....
Abandon all the rules. Well, abandon all the rules you don't completely
understand.
Do what makes your desired outcome happen. Rules exist to make that easier.
Follow whatever rules make your desired outcome happen with the least hassle
to your customer.
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.
That's hardly the end of the world. I think I can cope with that. I wish
I could recall where I got the suggestion in the first place and why it
was seen as a good thing to do but I just don't recall.
Because you can't recall the source or rationale for the rule, don't
understand the rule, and perhaps don't even recall the rule accurately, you
should not follow that rule. The policy of following ritual mumbo-jumbo from
half-remembered sources in a way not intended by the original promulgator of
that ritual mumbo-jumbo is that old, surefire path to failure known as
"cargo-cult programming".
....
As for the other packages in Common and CommonCandidate, I think the vast
majority are very soon going to be sitting in the same package,
com.novice.common since they are unrelated except that they are commonly
used. The vast majority are used independently, not together, so they
aren't really related. The few that are both related and common will get
their own packages. There! I've just put all the code in the Common
project into one big package. A small handful of types will get moved
again into separate packages as I figure out which ones really need that
treatment.
That sounds valid.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg