I'm trying to develop a fairly flexible routine to move text and images around a screen as part of a games library. There's a whole bunch of params that can be used so the position part might have X & Y and optionally a starting X & Y or perhaps no position info in which case it goes in the centre of the screen or perhaps it might reference one of the items on screen in which case the message will get printed near by. I have similar options on movement and timings and colours plus other random stuff. I don't want to have a single method with a 100 params. I tried defining different versions of the method that used different sets of params but I'd end up with 100's of methods instead. Today I started experimenting with passing a number of variable length arrays for the position, movement and timing info. This looked like a viable solution but
Is there a way of writing it like (A) that I'm missing?
Is there a better approach altogether?
The problem with (B) is that it looks messy and I'm not sure whether defining and creating all these arrays is efficient as it's used in various real time games.
I don't know what all of the variations are, all that random stuff, but my first question is why don't you have an object which you can pass to the method? Then the object could be designed to contain any or all random stuff needed by the method. And also the method could encapsulate all of the complexities involved in dealing with whether certain bits and pieces are there or not, and so on.
Thanks for the advice. I'll admit I come from a very procedural background and find OO a little weird. I did wonder why I saw definitions of arrays in the 2 formats ow I know.
Is there any performance cost in using arrays like this? or do I need to be more careful with garbage collection? I know this might not look pretty but it's infinitely better than the other approaches I've tried.
Many thanks for the fast responses!
Mich Robinson wrote:. . . Is there any performance cost in using arrays like this?
Performance is the last thing you should be worrying about. Get your code correct first: see whether there is a performance problem later.
You may find that the processing to work out the new location of your displayed text take 1μs or less (that is simply a guess). But it might take 10ms to repaint your display on screen (another guess), so you probably won't notice any performance issues. You will however notice performance issues if you are repainting too frequently. If you have several characters to move simultaneously, make sure all the movements are done before you call repaint(). Otherwise there is a risk that you will take 10ms for your repainting and try repainting more than 100× per second, and your display will start to move with the speed of an arthritic snail.
Alternative answer: no, I don't think there will be any performance difference between what you wrote and using an object as Paul suggested.
or do I need to be more careful with garbage collection?
Another case, I think, where you are putting the cart before the horse. Remember the Java® runtime (=JVM) does its own garbage collection, and that is all automatic, so (to a first approximation) you simply forget about garbage collection in Java® code.
I know this might not look pretty . . .
I'm afraid you are right there. I agree with Paul: create an object to encapsulate all those data, then you can say,