wood burning stoves 2.0*
The moose likes Beginning Java and the fly likes Best class to implement extensible arrays Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Best class to implement extensible arrays" Watch "Best class to implement extensible arrays" New topic
Author

Best class to implement extensible arrays

Tony Bateman
Ranch Hand

Joined: Mar 21, 2005
Posts: 42
Hi,

I'm new to Java, coming over from years of SAP ABAP coding.

I can see that arrays have to be declared as fixed at construction time.

What if I want to extend the size of the array at run time? What are generally accepted classes to use for such operations? (I assume that there are some). I would like to extend and possibly cut elements from the middle of the 'array', maintaining the order, to access an element by a key (not necessarily the index), and add to the end.

Oh yes, would also like it to be fast!

Kind regards,

Tony.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 5018
    
    8

Take a look at the Collections Framework classes in java.util.*
[ March 21, 2005: Message edited by: Junilu Lacar ]

Junilu - [How to Ask Questions] [How to Answer Questions]
Tony Bateman
Ranch Hand

Joined: Mar 21, 2005
Posts: 42
Will do,

Thanks for the quick reply!

Kind regards,

Tony.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Here's a Crib Sheet I use to keep my favorite collections straight.


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Tony Bateman
Ranch Hand

Joined: Mar 21, 2005
Posts: 42
Thanks for that too!

One question: on your web page you state:

"It is good practice to declare variables and parameter types with the interfaces and not the concrete classes".

Why is that?

Cheers,

Tony.
Horatio Westock
Ranch Hand

Joined: Feb 23, 2005
Posts: 221
Originally posted by Tony Bateman:
"It is good practice to declare variables and parameter types with the interfaces and not the concrete classes".

Why is that?


Consider the case where you create an implementation using some collection. Later you wish to change the semantics of the implementation, as the order of elements becomes important.

It is much easier to slot in a replacement instantiation of a concrete implementation that guarantees some order, in one place, than it is to go through all of your code, replacing method declarations etc.

Most code doesn't care about details, instead it only cares that some methods are available.

The item order example is quite specific, but writing your code to an interface rather than a concrete class is good practice in general.
Layne Lund
Ranch Hand

Joined: Dec 06, 2001
Posts: 3061
Originally posted by Tony Bateman:
Thanks for that too!

One question: on your web page you state:

"It is good practice to declare variables and parameter types with the interfaces and not the concrete classes".

Why is that?

Cheers,

Tony.

This paradigm is known as "coding to the interface not the implementation" (or something like that) and is a common way of thinking in any Object-Oriented programming language. I think Horatio's gives a good abstract explanation of the concepts, but I'd like to add a (perhaps) more concrete example.

Let's say you are working on a project where you need to index items with something other than an integer. Other languages provide this ability with some built-in type. After looking at the Collections framework in Java, you see that the
Map interface provides this functionality. You then need to choose a specific class that implements this. The typical choices are between TreeMap, which can order the elements, or HashMap, which does not preserve any specific order. Since ordering the elements adds some overhead and your particular project does not care about the order, you decide to use HashMap. Then you go about declaring variables, parameters, and return types with the HashMap class.

Now let's say that the requirements or design changes so that your application DOES care about ordering the elements. Now you have to go through all of your code and change HashMap to TreeMap. Obviously this will take some time and be a potential for errors.

If on the other hand, you originally declared all variables, parameters, and return types with the Map interface type, then you would only need to change a few places where you create the object! Think of the time savings this makes.

Admitedly, this example is somewhat contrived. However, I think it illustrates the benefites of using the interface instead of a particular concreate class. There are also other benefits, but I'll let you research it more if you are interested.

Keep Coding!

Layne


Java API Documentation
The Java Tutorial
Tony Bateman
Ranch Hand

Joined: Mar 21, 2005
Posts: 42
Hi,

Thanks for the last two posts; this really looks like a terrific place to post questions and get intelligent answers. Those posts have given me a good place to direct current studies. I'll mull these replies over until I get it!

Thanks heaps!

Tony.
 
Don't get me started about those stupid light bulbs.
 
subject: Best class to implement extensible arrays