Re: Design question - methods calling methods
Lew <noone@lewscanon.com> wrote in news:ht9k22$rkl$1@news.albasani.net:
Rhino wrote:
In all honesty, I hadn't even thought of SortedMap when I wrote the
code again the other day. I just knew that I wanted the result to be
in alphabetical order, not random the way that
Locales.getAvailableLocales() provides them. The article on the Map
interface pointed out that TreeMap would assure that I had
alphabetical order so I went with that. Now that you've reminded me
about SortedMap, I can see the merit of it. It's not much different
than TreeMap but it does give those additional features,
WTF are you talking about? I got lost in your antecedent-free
pronouns. Are you referring to the methods in 'TreeMap' that are not
implementations of 'SortedMap' methods?
As for 'SortedMap' not being "much different [from] TreeMap', well
that makes perfect sense since 'TreeMap' implements 'SortedMap'.
OTOH, some might say that an interface in some ways is always "much
different" from a concrete class, but that difference is the basis of
the recommendation to move to a wider ("looser") type.
like range operations. I don't see those as being _necessary_ for my
humble little getLocales() method, which I'm really just writing for
myself, but some future user of the class could conceivably benefit
from those extra features. Or maybe _I_ will get a benefit from those
features a little further down the road! I've modified the code to
produced a SortedMap - just replaced all "Map" with "SortedMap", dead
easy! - and reran my unit tests. Naturally, they still worked fine.
You're the API writer. YOU dictate what "some future user" gets to
do.
Fair enough.
It's a best practice to add a lot of "potentially useful" cruft to a
type. Implement what you need now, and refactor later if the need
arises.
(I saw your amendment about the missing "not" in that paragraph.)
I probably tend to overbuild a lot of the time anyway, in the sense of
adding functionality that isn't all that likely to be used. My current
thread about the internationalization/localization is proof of that. I
tend to anticipate needs that others aren't sure will ever happen. Not
all the time of course; it's just a tendency, not an obsession ;-)
If you need access the 'TreeMap' methods that aren't part of the
'SortedMap' interface, then by all means declare the variable that
needs that access as 'TreeMap', otherwise don't.
Hmm. Did I do this right?
I had this:
======================================================================
=== public Map<String, Locale> getLocales() {
Map<String, Locale> sortedLocales = new TreeMap<String, Locale>();
for (Locale oneLocale : Locale.getAvailableLocales()) {
sortedLocales.put(oneLocale.getDisplayName(locale), oneLocale);
}
return sortedLocales;
}
======================================================================
==
and changed it to:
======================================================================
== public SortedMap<String, Locale> getLocales() {
SortedMap<String, Locale> sortedLocales = new TreeMap<String,
Locale>(); for (Locale oneLocale : Locale.getAvailableLocales()) {
sortedLocales.put(oneLocale.getDisplayName(locale), oneLocale);
}
return sortedLocales;
}
======================================================================
==
Yes.
The first line of the revised method looks a bit funny:
SortedMap ... = TreeMap ....
LOL.
Since 'TreeMap' /is-a/ 'SortedMap', that's perfectly legit. You can,
and often should upcast without danger.
Did I do what you meant?
Yes.
Good :-)
Sigh! I still struggle with understanding what I am doing
sometimes.... I still don't REALLY understand the difference between
these:
- Map<String, Locale> sortedLocales = new TreeMap<String, Locale>();
This variable 'sortedLocales' only has access to features promised by
the 'Map' interface, not the additional methods of the 'TreeMap' or
'SortedMap' types.
It's also named with a lie, because the code could change to assign an
unsorted 'Map' to the variable without causing a compiler error, thus
creating a problem at run time. You never want to push
compile-time-avoidable mistakes to run time.
- SortedMap<String, Locale> sortedLocales = new TreeMap<String,
Locale> ();
The variable 'sortedLocales' has access to the methods of 'SortedMap'
but not those of 'TreeMap' not in the 'SortedMap' type. The name is
not a lie, because any refactoring of the code must use a 'SortedMap'
subtype to assign to the variable.
- Map<String, Locale> sortedLocales = new SortedMap<String,
Locale>();
This is "codecrap" as Eric likes to call it. It will not compile.
I was just throwing that out to illustrate the way these similar-looking
bits of code sometimes blur together in my brain....
Are you familiar with the difference between interfaces and classes?
I'm not sure how to answer that. I've read formal definitions of both and
have written both and gotten them to run. But even after all the time
I've spent writing Java - I started in 1997 but had a 4 year gap that
ended a few months back where I wrote no Java at all - I don't feel solid
on a lot of the theory. Maybe I'm expecting too much of myself but I feel
like I should know instantly and intuitively what the key differences are
between classes and interfaces and not have to wrestle with "should I use
an interface or class here". But maybe guys like you and Eric and Tom
have to think long and hard about that too. I really don't know.
- and so forth
"So forth"? What "so forth"? What do you mean?
Just that I could imagine other variants on the same sort of statements.
Or, by the same token:
These examples are by no means "the same token".
I didn't mean to suggest that the calendar examples had anything to do
with the Map examples, just that the three statements in each group LOOK
similar but have very important differences. Unfortunately, those
differences don't jump out at me when I see them used in examples or
whatnot. I feel like it should be dead obvious instantly why the
programmer wrote one or the other or what bad things would happen if I
changed one to the other. But that doesn't happen for me.
- Calendar cal = Calendar.getInstance();
This does not guarantee that you will get a 'GregorianCalendar' or any
other particular type of 'Calendar'.
- Calendar cal = new GregorianCalendar();
This guarantees that 'cal' points to a 'GregorianCalendar', but the
behaviors specific to 'GregorianCalendar' but not 'Calendar' cannot be
accessed through it.
- GregorianCalendar gcal = new GregorianCalendar();
This guarantees that 'gal' points to a 'GregorianCalendar', and the
behaviors specific to 'GregorianCalendar' can be accessed through it.
If I had to write an exam, clearly articulating the distinction
between those and what the implications of each is, I'd surely make a
hash of it....
cal.hashCode()
Good one :-)
That doesn't fill me with optimism about my ability to persuade an
employer that I would be a useful addition to their team. I imagine
they're going to want people that know that stuff backwards and
forwards....
No.
Employers hire people at all levels of experience and knowledge, with
appropriate adjustments to compensation, depending on the mix they
need for their team. I know of very few projects that hire only
virtuosos, and I've worked on many that actually hired incompetent
programmers.
Which last you aren't, BTW.
Well thank you, that's a very nice thing to say. Maybe I just expect too
much of myself. I suppose there's a certain envy here. I see guys like
you and Eric and Tom explaining things so articulately to people like me
and I wish that I had the confidence in my own ability to be able to
answer those questions as well. But it feels like 95% of the people in
this group know a lot more than I do.....
Still, I'm going to learn a lot more hanging around here getting
questions answered by people who know their stuff than by hanging around
with people who know less than I do. I'll keep plugging away at it. Maybe
in a couple of years I'll feel a little more capable of answering the
kind of questions most people here ask....
Thanks for your help with this - and so many of my other questions!
--
Rhino