File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes which one is better way ? pass object or list ? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "which one is better way ? pass object or list ?" Watch "which one is better way ? pass object or list ?" New topic
Author

which one is better way ? pass object or list ?

Alvin chew
Ranch Hand

Joined: Jan 08, 2004
Posts: 834
hi, i currently coding on a method , which suppose pass a group of same object instance but different contains, i not sure which idea is better , hope some expert here can enlighten me

the sample code as follow :


or should i


i will pass the obj[] or list to other method for insert data ..in my case, which one is better ?

thank you ...and if possible ...pls tell me the good n bad of the cases
Joshua Bloch
Author and "Sun God"
Ranch Hand

Joined: May 30, 2001
Posts: 124
Alvin,

Before 1.5, people tended to pass around arrays because it was the only way to get type safety: you had to cast the objects that you took out of the lists, and the cast could fail at run time. In 1.5, you can and should and use parameterized types (AKA generics) on your lists. This gives you *better* type checking than you ever got on your arrays: if the program compiles cleanly, you don't have to worry about ArrayStoreException when you're using List<T>. Also List admits multiple implementations. The standard implementation (ArrayList) works well in most cases, and you don't have to know the length ahead of time as you do for arrays. The downsides of using List<T> are: (1) It's likely to be a bit slower (generally not a big deal), and (2) creating and initializing lists is a bit more verbose, as they aren't supported directly by the language.

Regards,

Josh


Joshua Bloch <br />Author of <a href="http://www.amazon.com/exec/obidos/ASIN/0201310058/ref=ase_electricporkchop" target="_blank" rel="nofollow">Effective Java</a> and coauthor of <a href="http://www.amazon.com/exec/obidos/ASIN/032133678X/ref=ase_electricporkchop" target="_blank" rel="nofollow">Java Puzzlers</a>
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

I would say 98% of the time, you don't know the size ( at least with my experience. ) So if a developer is stuck at 1.4 or earlier, would you say it is better to use List if you don't know the size and Object array if the size is fixed?

BTW, the examples given leave a bit to the imagination, don't they?
Joshua Bloch
Author and "Sun God"
Ranch Hand

Joined: May 30, 2001
Posts: 124
Originally posted by Barry Andrews:
I would say 98% of the time, you don't know the size ( at least with my experience. ) So if a developer is stuck at 1.4 or earlier, would you say it is better to use List if you don't know the size and Object array if the size is fixed?

BTW, the examples given leave a bit to the imagination, don't they?


Yep. Also the second one would throw a NullPointerException

Josh
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Are we talking about passing a List to be populated by a method? That in itself has much nicer alternatives; I think this is obvious, so I will assume that you are *returning* a List from a method. The dangers here are a bit more subtle. Design By Contract (which is what you are doing even if inadvertantly) mandates that all contract participants (parameters and return types) are not mutable types. So how do you achieve what you want to achieve? Well simply put, the java.util.List should have been split, at least into mutability and immutability (sorry Josh ). The java.util.List interface violates the fundamental rule "two or more methods on an interface must be symbiotic (exist together or not at all)". Quite clearly, mutability and immutability does not exist symbitiocally. It would have been nice to return an immutable List, and it's quite possible by using delegation i.e. defining your own interface that is a subset of java.util.List containing only operations that do not modify the List, then delegate to an underlying instance of java.util.List. However, don't fall into the same trap - split out all operations that are not symbiotic. I should point out that declaring to throw UnsupportedOperationException is a suboptimal solution i.e. a workaround - avoid it where possible and use a statically typed language to enforce type-safety at compile-time as much as possible.

I did this so often that I decided I'd write my own sequentially ordered container. This example is certainly far from optimal and this has more political reasons than technical ones; for example, the length() method should have (and has been but it is not public code) split out into an interface Lengthable{int length();}, and there are a few other examples of "breaking the rules". Nonetheless, here is the type. You'll note that it is both immutable, and does not perform any data copying when an operation is invoked that returns a new sequence. That is to say, when you append a sequence containing "b" to a sequence containing "a", this does not mean that "a" and "b" are copied into a new sequence; merely an interface is returned that provides a new view of the same data.
http://www.jtiger.org/javadoc/org/jtiger/framework/Sequence.html

Anyway, I better stop ranting.
[ August 11, 2005: Message edited by: Tony Morris ]

Tony Morris
Java Q&A (FAQ, Trivia)
Barry Andrews
Ranch Hand

Joined: Sep 05, 2000
Posts: 523

A sequentially ordered set of elements that cannot be muted


Does that mean your Sequence has a lot to say?

Sorry, I could not resist.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
gah, sorry, *mutated* - I even made the same mistake in the javadoc
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: which one is better way ? pass object or list ?