Re: Design question - methods calling methods
Tom Anderson <twic@urchin.earth.li> wrote in
news:alpine.DEB.1.10.1005222205570.8422@urchin.earth.li:
On Sat, 22 May 2010, Rhino wrote:
Lew <noone@lewscanon.com> wrote in
news:ht76kf$e1c$1@news.albasani.net:
Rhino wrote:
... getLocales(), which returns a TreeMap, and then displays the
contents of the TreeMap on the console.
It's mostly a good idea to declare variables as an interface type
rather than a concrete type.
Rhino, read that sentence again.
The rule of thumb is that you declare the variable with the loosest
possible type that has the behavioral contract you need.
And that one.
And again.
Now proceed with the rest of this post.
Thus, you probably want 'getLocales()' to return a 'SortedMap', as
someone suggested in another thread, unless there's something
specific about 'TreeMap' in particular that requires you use only
that type or a subtype thereof.
For a second there, I had no idea what you were proposing.
But I reviewed the Collection Classes in the Java Tutorial and I
think I get it now.
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.
You make that desire concrete by the type of the object holding the
locales - you want them to be sorted, so it's a SortedMap.
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, 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!
You're on the wrong track here. The extra features are not what
SortedMap is about - it's fundamentally about that first paragraph in
its javadoc:
A Map that further provides a total ordering on its keys. The map is
ordered according to the natural ordering of its keys [...] This
order is reflected when iterating over the sorted map's collection
views (returned by the entrySet, keySet and values methods). Several
additional operations are provided to take advantage of the
ordering.
Yes, there are several additional operations. But the heart of the
matter is that the map has an order, which governs iteration over its
contents.
Sorry, I phrased my remarks poorly. I know the range handling and all
that are more along the lines of bonus features; the order of the data
is, of course, the main thing.
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.
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;
}
======================================================================
==
Spot on.
The first line of the revised method looks a bit funny:
SortedMap ... = TreeMap ....
Did I do what you meant?
Yes. You did *exactly* what Lew meant when he said:
It's mostly a good idea to declare variables as an interface type
rather than a concrete type.
SortedMap is an interface type - it says 'this map is sorted somehow'.
TreeMap is a concrete type - it says 'this map is implemented as a
red-black tree, which incidentally results in it being sorted'.
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>();
It happens to be a TreeMap, but all the type declares is that it's a
map.
- SortedMap<String, Locale> sortedLocales = new TreeMap<String,
Locale>();
It happens to be a TreeMap, but all the type declares is that it's a
sorted map.
- Map<String, Locale> sortedLocales = new SortedMap<String,
Locale>();
Illegal. SortedMap is an interface.
I didn't actually try that; I just threw it out to illustrate how these
things sort of all blur together in my brain....
Or, by the same token:
- Calendar cal = Calendar.getInstance();
- Calendar cal = new GregorianCalendar();
- GregorianCalendar gcal = new GregorianCalendar();
Those last two examples are an exact analogue. The first one is a
little different - but a natural extension of the idea.
The third version says "I care that this is object is specifically a
GregorianCalendar. I am going to do things with it which specifically
would not work with any other kind of calendar.". There are times when
you might want to say that, but you would strive to be more general -
in which case you would use the second version, which says "I care
that this object is a Calendar, but i don't care which kind of
calendar - it could be Gregorian, Islamic, Japanese Imperial, Darian
Jovian, etc". However, in the second form, although you will proceed
to write your code calendar-agnostically, you are actually hardcoding
the choice of GregorianCalendar there. You could change it later, but
you'd have to go through your code and change the constructions. In
the first form, you push the calendar-agnosticism even into the
creation itself - rather than explicitly using a GregorianCalendar,
you let Calendar decide what kind of calendar should be used. Right
now, that will presumably always be a GregorianCalendar, but if at
some point someone boots up your software on Ganymede (the moon, not
the Eclipse release), it should probably be Darian, and by leaving the
decision to Calendar.getInstance, you let that happen without having
to alter your code. You delegate the decision to someone in a better
position to make it.
Now, in this particular case, there is a major caveat: different types
of Calendar are not interchangeable in the way that different types of
Map are, because they represent different ideas. If you're using this
Calendar object to handle dates which are definitively in Gregorian
(January, February and all that), then you need an actual
GregorianCalendar, and you should declare your variables accordingly.
To paraphrase Einstein, "everything should be made as generic as
possible, but no more so".
Thanks for clarifying the differences between the two groups of
statements I listed above. You did quite a nice job and I feel that I
have a little better grasp of it. But I'd be lying if I really felt I
have a really solid handle on things. I feel like it should all be more
obvious somehow and not require me to rack my brain each time this kind
of thing comes up to try to understand just what the key distinction is
between X and X'.....
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....
That would be a real mistake. You should be making a tree. Have you
learned NOTHING?
LOL!! Good one!
I can tell if I'm getting a compile error and I can tell if my code
is doing what I want it to do but I still don't always understand WHY
one thing is better than an other or what the real difference is
between things that look very very similar.....
The choice between Map and SortedMap here is not one of correctness.
It's one of design and style. Good design and style doesn't change the
way code runs, but it makes it easier to understand and modify. A huge
part of the business of software is understanding and modifying
existing code, and so good design and style are valuable. They're
investment for the future, rather than the here and now.
I'm fine with those general principles. I have done maintenance
programming and I have been handed badly written programs that made me
cringe just to look at them - as I'm sure we all have. I've always gone
the extra mile to make my code just as good as I was capable of making it
in every way that I could: make it work, make it clear, make it easy to
read, etc.
Thanks for your advice and your clear explanations, Tom! Much
appreciated!
--
Rhino