I'd vote to split your monster up for design goodness, not performance. The usual advice is write for humans first and optimize only when you can prove you have found the worst performance problem in your system. Trying to second guess the swapping algorithm of the OS or how many instructions are involved in a method call is not the best use of your time.
"Design goodness" is a debatable topic of at least book length. If principles like make a class with only one reason to change, tell don't ask and so on sound interesting, scroll on down to the OO, UML, etc. forum and describe your giant class in a bit more detail.
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
posted 13 years ago
I just tried splitting a chunk of it off, but I kept get a stack overflow exception, I couldn't figure out why, so I put it back.
So long as performance isn't haltered by having a load of methods/variables in one class, I'm not too concerned.
One more thing, how does final work? I set an array (instance field) to final, but I was still able to modify the elements of it elsewhere in the code, doesn't look very final to me.
?? [ February 13, 2007: Message edited by: colin shuker ]
"final" affects only the variable it's applied to. A final variable of array type can't be changed to point to another array. But the array pointed to is just an ordinary array, and its elements can be set. There's no way to make a non-writeable array in Java.