TeamSuperGood

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!

This entry was posted on Wednesday, February 8th, 2006 at 7:17 am and is filed under Team, Programming. You can subscribe via RSS 2.0 feed to this post's comments. You can comment below, or link to this permanent URL from your own site. Your comments will appear immediately, but I reserve the right to delete innapropriate comments.