Here is a good example where refactoring code, makes things more readable, but also enhances the design.
This is what we were using before:
for (WhereClause wc : m_clauses) {
if (wc.m_objType == WhereClauseType.Bool) {
statement.setBoolean(++count, ((Boolean) wc.m_obj).booleanValue());
} else if (wc.m_objType == WhereClauseType.Int) {
statement.setInt(++count, ((Integer) wc.m_obj).intValue());
} else if (wc.m_objType == WhereClauseType.Long) {
statement.setLong(++count, ((Long) wc.m_obj).longValue());
} else if (wc.m_objType == WhereClauseType.String) {
statement.setString(++count, ((String) wc.m_obj));
} else if (wc.m_objType == WhereClauseType.InStream) {
statement.setBinaryStream(++count, ((BufferedInputStream) wc.m_obj), ((InStreamWhereClause)wc)._length);
}
}
By changing the SQLTerm (new version of WhereClause) so that its type is not an enum, but an actually java.sql.Types member, we can now do the previous lines as follows:
m_statement.setObject(m_count, term.Value, term.getType());
This is also really cool, because the design I have for plug-in augmentation, will greatly benefit from some of those new classes.
So did I mean for that to happen? Nops, but that’s what happens when you design for cleanness, things just fit together!