Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail
From: Novice <novice@example..com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Aspect questions?
Date: Mon, 27 Feb 2012 22:50:05 +0000 (UTC)
Organization: Your Company
Lines: 222
Message-ID: <XnsA006B6A5992DDjpnasty@94.75.214.39>
References: <XnsA0039B9FFFA32jpnasty@94.75.214.39> <ji8u23$f6m$1@news.albasani.net> <XnsA00493ECED98jpnasty@94.75.214.39> <jia398$bho$1@news.albasani.net> <XnsA0047B96E59BFjpnasty@94.75.214.39> <jibf3u$ee9$1@news.albasani.net> <XnsA004B034AE631jpnasty@94.75.214.39> <jibn8n$17s$1@news.albasani.net> <XnsA004BD220634Ejpnasty@94.75.214.39> <jibso4$bv2$1@news.albasani.net> <XnsA0057F0ABEC37jpnasty@94.75.214.39> <4f4a6b1d$0$290$14726298@news.sunsite.dk> <XnsA005A56D659E8jpnasty@94.75.214.39> <4f4ac151$0$291$14726298@news.sunsite.dk> <XnsA006353B5A95jpnasty@94.75.214.39> <jif4sl$uon$1@news.albasani.net> <XnsA0067FCB0ABB7jpnasty@94.75.214.39> <jigom7$e1d$1@news.albasani.net>
NNTP-Posting-Host: Dmxgbnvd+eoRDUV2lwYf7Q.user.speranza.aioe.org
X-Complaints-To: abuse@aioe.org
User-Agent: Xnews/5.04.25
X-Antivirus-Status: Clean
X-Notice: Filtered by postfilter v. 0.8.2
X-Antivirus: avast! (VPS 120227-0, 2012-02-27), Outbound message
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:12453

Lew <noone@lewscanon.com> wrote in news:jigom7$e1d$1@news.albasani.net:

> 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 wasn't panicking; I was just wondering if I needed to add that to my 
"to do" list of things to re-learn. Which is basically what you're 
suggesting I do. :-)


>> 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? 
> 
I've got interface List<E> and class ArrayList<E> (which implements List
<E> among other interfaces) but I don't have TreeList<E>. I mostly still 
use the Java 1.6 API but even the Java 1.7 API doesn't have a TreeList.
What did you mean to say? And what do you want me to learn? I'm guessing 
you want me to see how a class makes use of an Interface but possibly you 
have something more specific in mind?

>>>> 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!
> 
Okay, I had forgotten that. Eclipse has a separate dialog for creating an 
enum so it makes it feel as if it ISN'T a class but a whole different 
animal.

> 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>
>
Sorry. I'm not as lazy as you think. It's just that I feel like we're 
having a conversation in (almost) real time. I wouldn't tell someone to 
go off to look something up in a dictionary in a real time conversation; 
I'd just ask them what they meant. It's now clear to me that you don't 
view it that way; more like a student coming to a lesson and being given 
homework. Okay, I can do that too.
 
> 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".
>
Java is something like my 10th programming language and I don't remember 
seeing 'type' as standard terminology in any of the others. Forgive my 
ignorance....
 
> 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.htm
> l> "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, ..."
> 
You've made your point, Again, sorry.

>> 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"?
> 
No, of course not. But if you're suggesting that I'm a little too quick 
to take advice without thinking through just whether it is the right 
thing to do, then yes, I'm probably guilty of that sometimes. I will work 
on that.

>>>> 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".
> 
Agreed. Which is the why I'm asking some of these questions now.
> ...
>> 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.
> 





-- 
Novice