I just made a Java n-tuple which is type-safe.
I’m using some unconventional methods to achieve type-safety (I just made it for fun).
Can someone can give some input on improving it or some possible flaws.
public class Tuple {
private Object[] arr;
private int size;
private static boolean TypeLock = false;
private static Object[] lastTuple = {1,1,1}; //default tuple type
private Tuple(Object ... c) {
// TODO Auto-generated constructor stub
size=c.length;
arr=c;
if(TypeLock)
{
if(c.length == lastTuple.length)
for(int i = 0; i<c.length; i++)
{
if(c[i].getClass() == lastTuple[i].getClass())
continue;
else
throw new RuntimeException("Type Locked");
}
else
throw new RuntimeException("Type Locked");
}
lastTuple = this.arr;
}
public static void setTypeLock(boolean typeLock) {
TypeLock = typeLock;
}
@Override
public boolean equals(Object obj) {
// TODO Auto-generated method stub
if (this == obj)
return true;
Tuple p = (Tuple)obj;
for (int i = 0; i < size; i++)
{
if (p.arr[i].getClass() == this.arr[i].getClass())
{
if (!this.arr[i].equals(p.arr[i]))
return false;
}
else
return false;
}
return true;
}
@Override
public int hashCode() {
// TODO Auto-generated method stub
int res = 17;
for(int i = 0; i < size; i++)
res = res*37+arr[i].hashCode();
return res;
}
@Override
public String toString() {
// TODO Auto-generated method stub
return Arrays.toString(arr);
}
public static void main(String[] args) {
HashMap<Tuple,String> birthDay = new HashMap<Tuple,String>();
Tuple p = new Tuple(1,2,1986);
Tuple.setTypeLock(true);
Tuple p2 = new Tuple(2,10,2009);
Tuple p3 = new Tuple(1,2,2010);
Tuple p4 = new Tuple(1,2,2010);
birthDay.put(p,"Kevin");
birthDay.put(p2,"Smith");
birthDay.put(p3,"Sam");
birthDay.put(p4, "Jack");
System.out.println(birthDay);
System.out.println(birthDay.get(new Tuple(1,2,1986)));
birthDay.put(new Tuple(1,2,""),"");
}
}
Kudos on learning by doing. Here are suggestions of “opportunities” for improvement:
Only one kind of Tuple can ever exist (once Typelock is set). This hurts reusability and scalability in programs wanting to use multiple types of Tuples unless you resort to cut-n-paste reuse (BirthdayTuple, DimensionsTuple, StreetAddressTuple, …). Consider a TupleFactory class that accepts the target types and creates a tuple builder object to generate tuples.
The validity of “null” as a value in a Tuple isn’t documented. I think before Typelock is set, null is allowed; but after Typelock is set, code will generate a NullPointerException – this is inconsistent. If they are not allowed, the constructor should catch it and disallow it (regardless of Typelock). If they are allowed, then the code overall (constructor, equals, hashcode, etc) needs modification to allow for it.
Decide whether Tuples are intended to be immutable value objects. Based on its lack of setter methods, I’d guess so. If so, then be careful of “adopting” the incoming array –
lastTuple=this.arr. Even though its a var arg constructor, the constructor could be called with an array directly. The class adopts the array (keeps a reference to it) and the values in the array could be altered outside the class afterward. I’d do a shallow copy of the array, but also document the potential issue with Tuples with non-immutable values (that could be changed outside the Tuple).Your
equalsmethod lacks the null check (if (obj == null) return false) and the class check (eitherobj instanceof Tupleorthis.getClass().equals(object.getClass())). The equals idiom is well documented.There’s no way to view the values of a Tuple except through
toString. This protects the values and the overall immutability of , but I think it limits the usefulness of the class.While I realize its just an example, I wouldn’t expect to use this class for something like birthdays/dates. In solution domains with fixed object types, real classes (like Date) are so much better. I would imagine this class to be useful in specific domains where tuples are first class objects.
Edit
Been thinking about this. Here’s my take on some code (on github + tests):