This week's book giveaway is in the Other Languages forum.
We're giving away four copies of Functional Reactive Programming and have Stephen Blackheath and Anthony Jones on-line!
See this thread for details.
Win a copy of Functional Reactive Programming this week in the Other Languages forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

which one is better way ? pass object or list ?

 
Alvin chew
Ranch Hand
Posts: 834
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Barry Andrews
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 124
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Barry Andrews
Ranch Hand
Posts: 529
C++ Java Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
gah, sorry, *mutated* - I even made the same mistake in the javadoc
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic