Re: Design question - methods calling methods
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.
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.
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.
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.
Are you familiar with the difference between interfaces and classes?
- and so forth
"So forth"? What "so forth"? What do you mean?
Or, by the same token:
These examples are by no means "the same token".
- 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()
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.
--
Lew