This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
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.
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.
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?
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.
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!