rule of thumb in determining the return type

[-]

i have a method 'getNames()' which returns a list of names.

the problem is i have no idea whether i should make the return type a
"String[]" or a "List".

i am using a List inside the method and if i am returning a String[] i
will just call the toArray method. but then again, i can simply return
the List.

does anybody know the rule of thumb in deciding what return type is
appropriate?

 

[Thomas Weidenfeller]

i have a method 'getNames()' which returns a list of names.

the problem is i have no idea whether i should make the return type a
"String[]" or a "List".

i am using a List inside the method and if i am returning a String[] i
will just call the toArray method. but then again, i can simply return
the List.

does anybody know the rule of thumb in deciding what return type is
appropriate?

The "rule" is to look at how the returned data will most likely be used.
As a secondary "rule", if you almost exclusively use one particular data
structure for that kind of data in your code, try not to change it for
one particular method without a very good reason. Consistent usage of
one particular data structure makes maintenance simpler.

/Thomas

 

[Malte]

i have a method 'getNames()' which returns a list of names.

the problem is i have no idea whether i should make the return type a
"String[]" or a "List".

i am using a List inside the method and if i am returning a String[] i
will just call the toArray method. but then again, i can simply return
the List.

does anybody know the rule of thumb in deciding what return type is
appropriate?

I'd say it would depend you how you think the returned object will be
used by the caller.

 

[Tony Morris]

i have a method 'getNames()' which returns a list of names.

the problem is i have no idea whether i should make the return type a
"String[]" or a "List".

i am using a List inside the method and if i am returning a String[] i
will just call the toArray method. but then again, i can simply return
the List.

does anybody know the rule of thumb in deciding what return type is
appropriate?

Yes, there are guidelines.
Here is one "returning a mutable type from a method is nasty."
Arrays are intrinsically mutable.
List is mutable, but can be made immutable with runtime enforcement checks
(also nasty).
i.e. UnsupportedOperationException is a result of a design flaw (naughty
Bloch).

Better to write the minimal interface that is required for your clients and
provide a factory that constructs instances that are backed by one of the
core types as a matter of convenience (construct instances some other way if
you see fit). I understand that this opinion is not shared by a large
majority, but miseducation is prolific in this industry.

 

[Ryan Stewart]

Yes, there are guidelines.
Here is one "returning a mutable type from a method is nasty."
Arrays are intrinsically mutable.
List is mutable, but can be made immutable with runtime enforcement checks
(also nasty).
i.e. UnsupportedOperationException is a result of a design flaw (naughty
Bloch).

Bloch? I haven't read any of his stuff, but UnsupportedOperationExceptions are
declared in Collection and List to name two. That isn't Bloch's idea.

 

[Eric Sosman]

Yes, there are guidelines.
Here is one "returning a mutable type from a method is nasty."

Haven't heard it called "nasty" before. It's done
quite frequently in the standard Java classes, some of
which are said to have been the work of nice people. ;-)

Is every method that returns an Iterator or Enumeration
"nasty?" Is System.getProperties() "nasty?" How about
Thread.currentThread() and Thread.getThreadGroup()?
StringBuffer.append()? Calendar.getInstance()? (Well, the
entire Calendar class might be called "nasty," but I don't
think this is the reason.)

There are so many instances of this "nasty" practice
that I suspect the guideline as stated may have been taken
out of context. Can you elaborate?

 

[John C. Bollinger]

Bloch? I haven't read any of his stuff, but UnsupportedOperationExceptions are
declared in Collection and List to name two. That isn't Bloch's idea.

And Bloch was the primary architect of the Collections classes. If
UnsupportedOperationExceptions weren't his idea then he at least signed
off on them.

 

[Tony Morris]

Bloch? I haven't read any of his stuff, but UnsupportedOperationExceptions are
declared in Collection and List to name two. That isn't Bloch's idea.

Joshua Bloch wrote one of the best available (perhaps even *the* best?)
books on Java practices, titled, "Effective Java".
He and Neal Gafter are also releasing what I expect to be yet another
excellent book this year (OK, I've had a peek at what's in it, but even if I
hadn't, my opinion would be much the same)
http://www.amazon.com/exec/obidos/t...f=sr_1_1/103-0087351-5783839?v=glance&s=books.
Bloch designed and implemented Java 2 collections (among other things
including the Sun Java 1.5 compiler with Neal).

I disagree with the use of runtime enforcement for "an unsupported
operation".
I haven't consulted Josh to take up the argument, since I believe the result
is an obvious once, and one that he might not like to enter since I too,
made mistakes of a similar nature at one stage, that I am not proud of. I
suspect that he now knows better, but clearly, this is pure speculation.