I just stumbled across this page about anti-patterns on wikipedia. I find it helpful to read about worst practices almost as much as best practices. I think I've mentioned before how much I enjoy the Unmaintainable Code site. You can learn a lot by finding out what not to do.
As usual, I find that I'm guilty of some of the issues mentioned. In the case of the anti-patterns, I tend to use the "BaseBean" anti-pattern a lot. While I always found that putting it in my UML diagrams really confuses things (so I generally just omit it completely), I found that the ease with which the utility methods can be called to be quite elegant. Calling myObj.dump() to get a listing of my private variables seemed to work really nicely.
Now I find out that this is considered bad practice because the nature of the relationship between the base object and it's children doesn't make a lot of logical sense.
So now the trick is to change the nature of the relationship between these classes such that the utility object winds up being delegated to instead of inherited from. It's going to require a bit of refactoring to shuffle things about and I hope I can keep the syntax almost as simple as the anti-pattern method. I don't think it will be too bad, but I'd like to hear if you've built utility delegates and if you've run into any issues I should be aware of.
I'm guessing I'll be reworking my cfcBlaster as well. Luckily, I've always got so much free time to do little projects like this (just kidding!).