Re: Design question - methods calling methods
On 22.05.2010 01:57, Lew wrote:
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. The rule of thumb is that you declare the variable
with the loosest possible type that has the behavioral contract you need.
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.
Adding to that: Depending on what DisplayLocales does it might be
reasonable to give it an argument of Iterable<Locale> so it can display
Locale instances regardless from where they were obtained. If
displayLocales() does extensive formatting of Locale instances for
display, you might even cut your methods differently. If, on the
contrary you just need this one way to obtain and display Locales it is
most reasonable to have it like OP did it.
It's not that there is the one and only reasonable solution to
distribution of functionality across methods but it always depends on
circumstance. Often this means that during the life time of an
application things need to be refactored to adjust to changed requirements.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/