Re: alias for Integer
jrobinss wrote:
I am processing structures that contain integers, structures such as matr=
ixes used in statistical analysis. As I implement these as Maps of indexes,=
I use the class Integer, as in
// Map<matrix index, DB index> <- I'd like to remove this comment!
public static Map<Integer, Integer> myMap = ...;
Now what I'd like is to write
public static Map<MatrixIndex, DbIndex> myMap = ...;
The advantage is that the code is auto-documented, but even better that t=
he compiler will check that I never get mixed up in different indexes, by r=
elying on strong typing.
Usually, I would do this by extending the relevant class. But here it's I=
nteger, which is final.
That is kind of an antipattern. Joshua Bloch suggest to "Prefer compositio=
n to inheritance" in /Effective Java/ (2nd ed.). You could write a wrapper=
for 'Integer', but then 'Integer' already *is* a wrapper type.
Questions:
1. is this a bad good idea, and I should proceed with Integer?
It's not a terrible idea, necessarily, but it seems unnecessary.
2. if not, how would you implement this?
I would pick a type that actually helps. I don't see what you object to in=
'Integer', quite frankly.
3. is there any performance issue in defining my own classes instead of I=
nteger?
How could anyone possibly know the answer to this question?
My current solution is to define my own classes for replacing Integer, su=
ch as:
public final class MatrixIndex {
public final int value;
public MyIndex(int i) {value = i;}
}
Congratulations, you just re-invented 'Integer', but without any of its fea=
tures.
Now you have to go through all sorts of gyrations to translate your custom =
class to and from 'int'. Your code complexity goes up, and you have to mai=
ntain your own custom substitute for a fundamental API type. Thus your ris=
k of bugs and code-maintenance costs skyrocket.
How again does this help you?
I won't benefit from autoboxing, then... :-(
No one does.
(I'm just hoping it doesn't break too much of the code, because even thou=
gh it's mine to break, I don't have infinite time)
Why waste *any* time on this? Just use 'Integer'.
Note that (exceptionnally for me) performance *is* an issue here. I haven=
't yet narrowed it down, but the code executes very slowly and eats up much=
too much memory at the moment. I'm starting to optimize it, that's why I'm=
starting with strongly typing it to prevent errors.
"Optimize" and "prevent errors" are, at best, orthogonal, and at worst (and=
typically in this kind of premature action) the former interferes with the=
latter.
Yet you say them in the same breath as though they were the same thing.
They aren't.
Your "strong typing" isn't, really. 'Integer' already is a strong type.
As for what you choose to "optimize", what evidence (that is, factual data =
derived from actual tests whose protocols are publicized) do you have that =
you are attacking the slow parts?
IOW, what /actual/ tests have you performed, and how did you control the va=
riables like system load, HotSpot warmup and application load?
You have a performance problem. So you decide to obfuscate random parts of=
your code base with zero foundation for your actions. Now you have two pr=
oblems.
--
Lew