Funny story at work today about several domain objects in our webapp codebase with
extremely verbose toString() methods. You know, you've seen these before:
public class Frob {
public String toString() {
StringBuffer buf = new StringBuffer();
buf.append(getClass().getName()).append(":");
buf.append("foo=").append(getFoo()).append(",");
buf.append("bar=").append(getBar()).append(",");
buf.append("baz=").append(getBaz());
return buf.toString();
}
}
Somehow, these toString() methods are supposed to be handy. The next logical
step of course is to litter your code with logger statements that dump objects out to the
console:
public void doIt(Frob f) {
logger.fine("Value of frob in doIt: " + f);
}
As it happens, we use a proprietary JDO implementation for persistence in our webapp,
which works great most of the time, but in this case the "magic" of bytecode enhancement,
transparent persistence, fetch groups and lazy-loading of fields really bit us, because it
turned out that there were objects not unlike the above which not only printed out all
values of their own fields but all children objects as well. A little while later after
iterating through a couple dozen such objects and dumping them out with logger statements,
the code had fired some 22,000 select statements at the database in the
course of a single web request.
I just may never write another single logging statement or toString() method
in my career.
5:29:13 PM 
|
