Code design

I'm trying to make better structured code, and I have this sort of love hate relationship with OO. Well mostly hate, but it's what I know so it's also what I use.

There's one problem I'm always coming back to and I've yet to solve; Is it ok to use classes to lump code? I know a hardcore old-schooler would scream no, but does it in any way hurt? Say I have this small operation which requires a state but I really don't want to pass it around as data and I shouldn't have more than one of it, do I make it a class or a module or whatever you'd call it?

Somehow it feels better to make it an object, perhaps mostly because again, it's what I'm used to. If the tiny system requires dynamic data, I can blame not deleting the object rather than not shutting down the system. If it's all static, then I still get the feeling that "here it is, right here!", if you know what I mean.. Actually if I make all the member variables and methods static, is there really any difference at all? So if it's not static, is there any difference other than that the state will be lumped as an object on the heap instead?

At the same time it hurts to think that there's an object out there.. which is simply not an object at all.

>>34
It's a lot less overhead than a standalone GUI app.